Re: [Yaffs] yaffs erases all files on mount

On Friday 15 April 2011 01:28:57 Nick Thompson wrote:
> On 13/04/11 22:42, Charles Manning wrote:
> > On Wednesday 13 April 2011 22:48:18 Nick Thompson wrote:
> >> yaffs [master] snapshot from today, linux 2.6.33-rc4
> >>
> >> I have patched my kernel with yaffs for testing.
> >>
> >> I did:
> >>
> >> flash_eraseall /dev/mtd3
> >> mount -t yaffs /dev/mtdblock3 /mnt/nand
> >> cd /mnt/nand
> >> touch test
> >> cd ..
> >> umount nand
> >> mount -t yaffs /dev/mtdblock3 /mnt/nand
> >> cd nand
> >>
> >> ls showed no files (except for lost+found). I turned on logging of erase
> >> blocks (YAFFS_TRACE_ERASE) and dmesg showed the following:
> >>
> >> yaffs: dev is 32505859 name is "mtdblock3" rw
> >> yaffs: passed flags ""
> >> yaffs: yaffs: Attempting MTD mount of 31.3,"mtdblock3"
> >> yaffs: auto selecting yaffs2
> >> yaffs: block 2255 is bad
> >> yaffs: block 2572 is bad
> >> yaffs: block 2574 is bad
> >> yaffs: block 3387 is bad
> >> yaffs: block 3843 is bad
> >> yaffs: block 3845 is bad
> >> yaffs: block 4033 is bad
> >> yaffs: yaffs_read_super: is_checkpointed 0
> >> yaffs: dev is 32505859 name is "mtdblock3" rw
> >> yaffs: passed flags ""
> >> yaffs: yaffs: Attempting MTD mount of 31.3,"mtdblock3"
> >> yaffs: auto selecting yaffs2
> >> yaffs: block 2255 is bad
> >> yaffs: block 2572 is bad
> >> yaffs: block 2574 is bad
> >> yaffs: block 3387 is bad
> >> yaffs: block 3843 is bad
> >> yaffs: block 3845 is bad
> >> yaffs: block 4033 is bad
> >> yaffs: yaffs_read_super: is_checkpointed 0
> >> yaffs: yaffs_block_became_dirty block 1 state 8
> >> yaffs: Erased block 1
> >>
> >> Obviously it didn't like the fist block, which I assumed had my file in
> >> it, and decided to erase it.
> >
> > This is almost certainly due to your flash driver mangling the tags
> > stored in oob.
> >
> >> What else should I log to try and figure out what is going on?
> >
> > Turn on some of the MTD level and verification tracing in yaffs.
> >
> > You might also want to add some printks to the flash driver.
> >
> >> jffs2 on
> >> the same partition passes this same test, so I believe the NAND is work
> >> okay.
> >
> > JFFS2 does not use oob so makes different use of the flash driver. It is
> > possible for one fs to work and another not if a driver is broken.
> >
> > -- Charles
>
> Thanks Charles, that is useful input.
>
> I sprinkled printks around like confetti and couldn't find anything really
> wrong, but I did notice the yaffs tracing showing eccres of 3 in many
> places.
>
> This prompted me to check the NAND driver again, but in the end it seems
> this is due to yaffs_UnpackTags2 running its own ECC checks, which detects
> errors that it can't fix.
>
> I tuned checking off by default (CONFIG_YAFFS_DISABLE_TAGS_ECC=y) and
> things look better now.
>
> Is this because the number of free bytes in my OOB is not enough?
> I have
> 22 free bytes starting as offset 2. I guess that the tag data fits, but
> the ECC doesn't. sizeof(yaffs_PackedTags2TagsPart) + sizeof(yaffs_ECCOther)
> is 28 bytes I think.

Yes that is right. The default tags want 28 bytes.

>
> Maybe I'm wrong about that and it's simply not being written correctly -
> though that would seem odd as I assume the tag data itself is okay...
>
> Is it safe to turn off the extra ECC? I assume without it the tag data is
> not protected in any way. That doesn't sound very safe.

It depends on whether or not your current ECC scheme provides protection for
those tags or not.

The other option is to go for a smaller implementation of yaffs_ECCOther. This
is currently 3*u32 = 12 bytes but since only the LSB is useful this could
actually fit in 3*u8 = 3 bytes, giving a total of 19 bytes.

-- Charles