UBIFS Corrupt during power failure

Eric Holmberg Eric_Holmberg at Trimble.com
Fri Apr 10 14:33:56 EDT 2009


> On Fri, 2009-04-10 at 11:00 -0600, Eric Holmberg wrote:
> > Thank you very much for your help so far. 
> NP, this is all I can do now without having real NOR and much time :-)
> 
> >  I am going to do two things:
> >  1. Turn off write buffering which converts the NOR minimum 
> I/O size from 1 to effectively 32 16-bit words (64 bytes) and 
> re-run all of the tests.
> 
> Err, which buffering? Is this something at the flash driver level? 

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.  This is what I used for the tests with
U-Boot and it is why you see patterns such as the one below.  The code I
used to write this pattern to flash wrote the entire block in 1 write.
The CFI driver then broke up the writes into 64-byte writes.
Apparently, it didn't do them in order (or the flash chip didn't), which
is why you have aa55aa0a values after ffffffff values.  Turning off the
write buffering in the CFI driver by setting FORCE_WORD_WRITE to 1
should solve this (although it will now probably be somewhere between
10x and 32x slower).


30352250  aa55aa0a aa55aa0a aa55aa0a aa55aa0a 
30352260  aa55aa0a aa55aa0a aa55aa0a aa55aa0a 
30352270  aa55aa0a aa55aa0a aa55aa0a aa55aa0a 
30352280  ffffffff ffffffff ffffffff ffffffff 
30352290  ffffffff ffffffff ffffffff ffffffff 
303522a0  ffffffff ffffffff ffffffff ffffffff 
303522b0  aa55aa0a aa55aa0a aa55aa0a aa55aa0a 
303522c0  ffffffff ffffffff ffffffff ffffffff 
303522d0  ffffffff ffffffff ffffffff ffffffff 

Does that make sense now, or am I on the wrong path?

-Eric

> 
> Note, UBIFS never talks to MTD level, it talks only to UBI 
> level, which talks to MTD. UBI will provide UBIFS min. I/O 
> unit size which it reads from mtd->writesize.
> Then if it is < 8, UBIFS will use 8 instead. There is not 
> fundamental reason for this, it was just easier to implement 
> UBIFS this way. But this is not big deal.
> 
> In your case, as I see from your logs, min. I/O unit reported 
> from MTD to UBI is 1, and from UBI to UBIFS it is 1, but then 
> UBIFS will use 8 instead. This means all write commands UBIFS 
> will issue will be aligned to 8 and be multiple of 8.
> 
> So if you are talking about turning off some buffering on MTD 
> level, may be it is ok. But if you are talking about UBIFS 
> level - no need to do anything there.
> 



More information about the linux-mtd mailing list