I have several NANDs that yaffs2 module would consider itself successfully recovered from check pointing and skip scanning, but the filesystem is not usable. Mounting with option no-checkpoint-read could recover the filesystem.
I understand that bad block management shall be provided from MTD layer, and rescanning fixing the problem proved MTD is doing his job. But I do have some questions:
1. why in the first place the check point restoring succeeded but left a corrupted filesystem?
2. What would happen if a used block become a bad block? will the whole filesystem got crazy? Any way to recover from it?
3. Any way to check or indicate an inconsistence in the filesystem, so the mounting script could try with the option no-checkpoint-read?
Thanks for your work and help. Please let me know if there's any mistake in my understanding.
regards,
Peter
does the official kernel has this function enabled or is there any option that controls it?
On 2010-03-04 20:55, Charles Manning wrote:
> On Friday 05 March 2010 07:14:59 Shivdas Gujare wrote:
> > Hi Charles,
> >
> > Thanks lot for your help.
> >
> > On Wed, Mar 3, 2010 at 12:34 PM, Charles Manning
> >
> > wrote:
> > > On Wednesday 03 March 2010 23:33:31 Sven Van Asbroeck wrote:
> > >> Hello Shivdas,
> > >>
> > >> > So, what does actually "check pointing" saves while
> > >> > unmount?
> > >>
> > >> It's my understanding that the check point consists of the RAM data
> > >> structure which is assembled when a yaffs partition is scanned. It
> > >> consists of meta-information associated with each chunk and block. If
> > >> you'd like to know more, I recommend reading the 'How Yaffs works'
> > >> document, which is available in CVS.
> > >
> > > A full scan builds up a set of data structures that define the file
> > > system state. A checkpoint captures a reduced version of that, enough to
> > > reconstitute the main part of the state and the rest can be built up on a
> > > lazy basis.
> > >
> > >> > and Is it
> > >> > safe to use check-pointing always in final product?
> > >>
> > >> According to Charles, checkpointing is designed to be used in the way
> > >> you describe. To my knowledge, no open checkpointing issues exist, but
> > >> you should search the archives. If you are concerned about the
> > >> checkpoint diverging from the meta-information on flash, you could a)
> > >> disable checkpointing altogether, or b) submit a patch implementing a
> > >> checkpoint counter ;-)
> > >
> > > You can also choose to mount ignoring checkpointing with
> > >
> > > mount -t yaffs2 -o"no-checkpoint-read" ..
> >
> > This is not the option for me, since in final product, end user should
> > not be able
> > to change system data (i.e. mount flag's.) Or I can't change it unless
> > rootfs is flashed
> > on device, since yaffs2/nand partitions are mounted from rcS script.
> >
>
> You don't need to do this. Just leave checkpointing on.
>
> -- CHarles
>
>
> -- Charles
>
>
-Peter
(text/plain)