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.
Thanks and Regards,
Shivdas Gujare
.
>
> -- Charles
>
>
>
(text/plain)