UBIFS Corrupt during power failure
jamie at shareable.org
Wed Apr 15 12:09:21 EDT 2009
Eric Holmberg wrote:
> > On Tue, 2009-04-14 at 19:00 +0100, Jamie Lokier wrote:
> > > Artem Bityutskiy wrote:
> > > So it would be correct for UBIFS to know that writes of N > 64(*)
> > > bytes may be broken into blocks, with corruption distributed
> > > anywhere within each of those blocks, but not more than one block.
> > I though the corruption will be inside the last block, because they
> > are written sequentially.
> Both are correct. The corruption will be in the last block written to
> the physical flash, but if the original UBIFS block write size is >
> FLASH_MAX_BLOCK_WRITE_SIZE, then the MTD CFI driver will split it into
> multiple smaller blocks. The CFI code appears to write out the split
> blocks sequentially from lowest address to highest address, but the
> actual physical flash chip doesn't always write the flash words out
We all have the same idea, that's good :-)
> So, if we assume that the MTD CFI driver will always split blocks into
> write-buffer sized blocks and write them sequentially (this is how the
> code is currently written), then the maximum corruption due to an
> interrupted write will be FLASH_MAX_BLOCK_WRITE_SIZE (which is 64 bytes
> for my case).
Is this really different from NAND and it's page writes?
Do the CFI block writes have to be aligned (to 64 bytes) offset, or
can the 64 bytes start at any word position?
> I'll take a look at what is involved in exporting the two values.
Good plan :-)
More information about the linux-mtd