Re: [Yaffs] more tragedy than ancient greece

> On 05/16/10 23:02, Charles Manning wrote:
> > On Monday 17 May 2010 01:09:27 yaffs@piments.com wrote:
> >> Hi,
> >>
> >> I have been using 2.6.29 patched to yaffs2 and it works fine.
> >>
> >> I am now trying to move to 2.6.32.11 , all is well except yaffs.
> >>
> >> Booting via nfs I have one fs image for *29 and  another for *32
> >>
> >> Booting to *29 I can mount /dev/mntblock1 , it is clean and df shows
> >> correct values.
> >>
> >> # mount -t yaffs /dev/mtdblock1 /mnt/tmp
> >> yaffs: dev is 32505857 name is "mtdblock1"
> >> yaffs: passed flags ""
> >> yaffs: Attempting MTD mount on 31.1, "mtdblock1"
> >> yaffs: auto selecting yaffs2
> >> Partially written block 513 detected
> >> Partially written block 513 detected
> >> Partially written block 513 detected
> >> ...
> >> /dev/mtdblock1 on /mnt/tmp type yaffs (rw)
> >> # df -h
> >> Filesystem                Size      Used Available Use% Mounted on
> >> /dev/root                 4.1G      3.6G    319.6M  92% /
> >> tmpfs                    64.0K         0     64.0K   0% /dev
> >> /dev/mtdblock1          125.0M     34.2M     90.8M  27% /mnt/tmp
> >>
> >>
> >>
> >> Booting from *32 when I try to mount /dev/mtdblock1 I get a shitload of
> >> tragedy.
> >>
> >> # mount -t yaffs2 /dev/mtdblock1 /tmp/mnt
> >> ...
> >> **>>  Block 972 needs retiring
> >> **>>  Block 973 needs retiring
> >> **>>  Block 974 needs retiring
> >> **>>  Block 975 needs retiring
> >> **>>  Block 976 needs retiring
> >> **>>  Block 977 needs retiring
> >> **>>  Block 978 needs retiring
> >> **>>  Block 979 needs retiring
> >> **>>  Block 980 needs retiring
> >> **>>  Block 981 needs retiring
> >> **>>  Block 982 needs retiring
> >> **>>  Block 983 needs retiring
> >> **>>  Block 984 needs retiring
> >> **>>  Block 985 needs retiring
> >> **>>  Block 986 needs retiring
> >> **>>  Block 987 needs retiring
> >> !!!!!!!!! Allocator out !!!!!!!!!!!!!!!!!
> >> yaffs tragedy: no more erased blocks
> >> !!!!!!!!! Allocator out !!!!!!!!!!!!!!!!!
> >> yaffs tragedy: no more erased blocks
> >> !!!!!!!!! Allocator out !!!!!!!!!!!!!!!!!
> >> yaffs_read_super: isCheckpointed 0
> >> ...
> >>
> >> I've checked the two .config files have the same  yaffs options
> >>
> >>
> >> This is rather reminiscent of the case where I moved from 2.4 to 2.6
> >> where I had similar types of problems and had to erase_all and install a
> >> new fs. Since the older kernel was years old and it was a major update I
> >> deemed this was acceptable and cleared the whole fs. Now it seems less
> >> normal.
> >>
> >> Is this something I am doing wrong or is there no attempt to keep yaffs2
> >> stable across kernel versions, even minor updates?
> >>
> >
> > This is happening because yaffs is seeing write errors. If every block has
> > write errors and needs to be retired then eventually there are no usable
> > blocks.
> >
> > This is almost certainly a change in the way mtd is handling the oob data.
> >
> > What happens if you erase the flash before mounting it?
> >
> > Have a detailed look at the way mtd oob data is being handled.
> >
> > -- Charles
> >
> >
> >
> Thanks Charles,
> 
> I have checked that the .config MTD options are the same in the two 
> kernels. So, is what you're saying that this is almost certainly coming 
> from changes in the way the kernel mtd code handles oob ?
> 
> Is this likely to be finger trouble on my part or is it to be expected 
> that the code will not be stable from one kernel release to another? 
> Specifically from 2.6.29 to 2.6.32
> 
> The main purpose of yaffs is reduce flash wear. Mounting the mtd block 
> device is a means of testing the kernel before committing to using it.
> 
> I will very likely erase_all and install the new fs when I commit. What 
> I don't want to do is erase it , burn the fs , find a problem , erase it 
> burn the old fs as a test cycle then start again.
> 
> I can't allow myself to get distracted into debugging the kernel mtd 
> handlers , what I need to know is whether this a sign that something is 
> badly wrong with this jaffs on this build or whether this is to be 
> expected when trying to mount a block created by an earlier kernel.
> 
> Are you able to comment on that?