UBIFS Corrupt during power failure

[Artem Bityutskiy]

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.

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

Right, I did not mean that. I meant that we can teach recovery code
to understand that the corruption may be withing 64-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.

No, does not seem to be very useful.

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

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.

-- 
Best regards,
Artem Bityutskiy (Битюцкий Артём)