Re: UBIFS partition on NOR flash not mountable after power cut test

[Norbert van Bolhuis <nvbolhuis@aimvalley.nl>]

Artem Bityutskiy wrote:
> On Wed, Dec 1, 2010 at 11:55 AM, Anatolij Gustschin <agust@denx.de> wrote:
> 
>> On Tue, 30 Nov 2010 20:18:56 +0200
>> boaz ben david <boazbd@gmail.com> wrote:
>>
>>> Sorry to bump the thread but I'm having issues which I think are similiar
>>> with MLC NAND flash.
>>> Will reducing the write buffer help here too?
>> I don't know. Your issues may look similar but without
>> knowing the details it is not possible to say. Most
>> probably no. I reduced the write buffer size in the CFI
>> driver. The issues we observed seem to be NOR flash
>> specific.
>>
> 
> Hi,
> 
> let me try to explain this. Both UBI and UBIFS have a notion of min_io_size.
> It is
> NAND page size in case of NAND. In case of NOR, UBI reports min_io_size as
> 1.
> So UBI assumes NOR flash writes one byte at a time.
> 
> Since UBIFS align all flash nodes to 8 bytes, UBIFS assumes min_io_size for
> NOR is 8 bytes. See fs/ubifs/super.c:
> 
>         /*
>          * UBIFS aligns all node to 8-byte boundary, so to make function in
>          * io.c simpler, assume minimum I/O unit size to be 8 bytes if it is
>          * less than 8.
>          */
>         if (c->min_io_size < 8) {
>                 c->min_io_size = 8;
>                 c->min_io_shift = 3;
>         }
> 
> Then the UBIFS scanning and recovery code is trying to be very picky about
> how
> nodes are corrupted. We wanted to distinguish between corruptions caused by
> power cuts and corruptions caused by something else. UBIFS policy is that it
> should
> gracefully recover from all corruptions cause by power cuts, and it does not
> try to
> recover from other types of corruptions.
> 
> Thus, in journal recovery code, if we see that we have good node, good node,
> good
> node, then some trash, we analyse this trash. We check that the amount of
> trash is
> not longer than maximum UBIFS node size aligned up to min_io_size, and then
> after
> this go all 0xFFs. And some other checks. See no_more_nodes() function.
> 
> In your case what happens is that we look that the amount of corrupted data
> is longer
> than common header size (all nodes start with the common header) aligned up
> to
> the min_io_size. And since we assume data is written min_io_size bytes at a
> time
> (8 bytes, next 8 bytes, etc in your case), we assume that the common header
> was
> successfully written, and we check it. But it is corrupted in your case,
> simply because
> you write 64 bytes at a time, no 8. And we reject the flash.
> 
> So all you need to do is to teach UBIFS to look at CFI write buffer size,
> and make
> min_io_size to be the same. Then it should work fine.
> 
> Try hacking UBIFS and make min_io_size to be 64. If it works, you can
> provide a
> nice solution - add corresponding field to mtd_info structure and teach UBI
> to look
> at it.
> 


A while ago I hacked mtd/ubi to hold CFI write buffer size in oobsize
in case of NOR flash. We have NOR devices with 64 (SPANSION) and 1024
(Numonyx™ Axcell™ M29EW) bytes write buffer size.
I never submitted it to this list because I considered it a hack
(and was rather busy).

I'm even more busy now, but I can cook up the patches and send them if
you want (hopefully I have time this evening or tomorrow).

It's only for testing (private kernel) since I assume it's not acceptable
to abuse oobsize this way (for NOR flash) ?

---
N. van Bolhuis.