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
>
> <manningc2@actrix.gen.nz> 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