UBIFS Corrupt during power failure

Eric Holmberg Eric_Holmberg at Trimble.com
Wed Apr 15 11:17:32 EDT 2009


> On Tue, 2009-04-14 at 19:00 +0100, Jamie Lokier wrote:
> > Artem Bityutskiy wrote:
> > > > This is for the CFI flash interface.  The
> > > > drivers/mtd/chips/cfi_cmdset_0002.c driver has write 
> buffers which is
> > > > uses to do a "block" write to the NOR flash which for 
> my chip allows
> > > > writing up to 32 16-bit words. 
> > > 
> > > Oh, this is something from the CFI standard? Then we may 
> just add this
> > > knowledge to UBIFS: if this is NOR, then UBIFS knows that 
> the up to 64
> > > bytes may contain garbage.
> > 
> > I think the block write size is only used when you _submit_ 
> a write of
> > that many words or more.
> 
> Yes, this is my understanding too.
> 
> > 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
sequentially.

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).

> Right. I assumed the same, may be I just did not put it clearly. But
> thanks for this suggestion.
> 
> > That means MTD and UBI should export two values:
> > 
> >     - Maximum block write size which may be affected by 
> power failure / reset.
> >       (Maybe that needs an alignment too.)
> 
> Yup. MTD does not inform about this ATM, though.
> 
> >     - Minimum write size for padding written items.
> >       (Is that assumed aligned?)
> 
> Right.
> 
> > For this particular NOR, the two values would be 64 bytes 
> and 1 byte.
> > I don't think it's specific to CFI.
> 
> Agree.

I'll take a look at what is involved in exporting the two values.

-Eric




More information about the linux-mtd mailing list