UBIFS data integrity

[Artem Bityutskiy]

On Thu, 2014-01-16 at 09:12 +0000, Mats Kärrman wrote:
> On Thursday, January 16, 2014 9:16 AM, Artem Bityutskiy wrote:
> > > UBIFS writes in 4KiB units.
> > 
> > I guess this is a bit confusing. The low-level flash write operations
> > can be bigger or smaller. However, the file data "buffers" that UBIFS
> > writes contain 4KiB of file data (aligned, e.g., regions of the file
> > would be 0-4K, 4K-8K, etc). Every such "buffer" is protected with CRC32,
> > and if a power cut results in the buffer not being fully written, the
> > CRC32 mismatches and UBIFS discards the entire buffer. And the old
> > contents of this file region is stays on the flash. The old contents
> > does not go away before the new contents reaches the flash media. So the
> > read operation for any aligned 4KiB region always returns the old
> > contents, or the new contents, nothing else.
> > 
> > >  So any aligned 4KiB piece of your file is
> > > guaranteed to either be fully written, then the read will return new
> > > data, or not be written at all, then the read will return old data.
> 
> Sorry if I mislead you, I guess the final statement of my original mail is
> still valid then:
> "In general this requires that your database also is implemented
> in a fault tolerant way."
> I.e. it must itself make sure it's entire write is completed before
> switching to a new "state". Unless the DB implements some kind of
> journaling this may be a problem.

Sure. The ordering or the 4K writes is not guaranteed, but I think the
memory management subsystem uses LRU lists so older writes go first. Any
write that crosses the 4096 byte-aligned boundary is not atomic. So the
only thing UBIFS guarantees is something like:

fsync
write(4k-5k)
fsync

will guarantee that the 1K piece of data either gets fully written or
not at all.

-- 
Best Regards,
Artem Bityutskiy