UBIFS Corrupt during power failure
dedekind at infradead.org
Wed Apr 15 02:00:37 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.
> 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?)
> For this particular NOR, the two values would be 64 bytes and 1 byte.
> I don't think it's specific to CFI.
Artem Bityutskiy (Битюцкий Артём)
More information about the linux-mtd