Re: UBIFS Corrupt during power failure

[Jamie Lokier <jamie@shareable.org>]

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.

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.

But it doesn't mean the minimum safe write size is 64(*), because if
UBIFS writes (say) 16 bytes for a small update, then the corruption
should be limited to just those 16 bytes.

If you wrote a 16-byte item which encodes "and the next item I write
will be 16-byte too", then you know if you see >16 corrupt bytes after
the item that it's not due to power failure.  This even with a 64 byte
buffer on the flash chip, because you know you will have done only a
16 byte write in that position.

I don't know if it's useful for UBIFS and its block scanning
algorithm to consider item sizes in that much detail.

The main thing is you can write smaller items safely, so you don't
have to pad them to 64 bytes and wear out the flash faster.  But
scanning may need to use a 64 byte window to decide the corruption type.

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

    - Minimum write size for padding written items.
      (Is that assumed aligned?)

For this particular NOR, the two values would be 64 bytes and 1 byte.
I don't think it's specific to CFI.

-- Jamie