On Thursday 01 April 2010 13:57:03 James Kehl wrote:
> > -----Original Message-----
> > From: yaffs-bounces@lists.aleph1.co.uk [mailto:yaffs-
> > bounces@lists.aleph1.co.uk] On Behalf Of Charles Manning
> > Sent: Thursday, 1 April 2010 10:04 AM
> > To: yaffs@lists.aleph1.co.uk
> > Subject: Re: [Yaffs] Periodic Checkpointing
>
> ...
>
> > Another approach that I keep mentioning, and should really get around
>
> to
>
> > doing, is implementing "block summaries". This would use the last
>
> chunk in
>
> > each block to hold all the tags for chunks in the block. That makes
> > scanning
> > way, way, faster meaning that the fallback for handling the case when
> > there
> > is no current checkpoint is still approaches checkpoint speed.
>
> Wouldn't this only be a gain for the inband-tags case, or when the MTD
> driver can't read out a page's tags without reading out the entire page
> as well (as some hardware ECC forces you to do)?

This should be beneficial all the time for the following reasons:
*The actual NAND page read costs the same time regardless of the number of 
bytes being fetched from the page. Thus you'd be doing one of these rather 
than 64. At, say, 20us per page read that's over 1ms of read time saved per 
block.
* The summary would also reflect chunk deletions that happened before the 
block was filled. Thus should speed the scanning somewhat for some use cases.

>
> It would be interesting if this also let you save chunk
> deletion/obsoletion flags - I heard someone pondering an
> "incremental/background mount" idea once, where more files would become
> available as the scan progressed. 
> > (Of course, any readdir() or access to  
> a non-existent file would have to block until the scan finished... but
> with a usual layout, it might get init started a couple of seconds
> earlier.) The biggest catch would be making sure old data (old
> filenames, deleted files, old contents) weren't temporarily resurrected.

In yaffs2 mode there are no problems with a scan building up obsolete data 
because yaffs2 mode scans backwards so we always know that some data or a 
file etc has been obsolteted before we stuff it into the tree.  Of more 
concern is incomplete data. If the directories and the files are only 
partially populated then you can't tell the difference between a non-existent 
directory entry and one that is still coming, or a sparse file and one that 
is only partially populated with more data on the way.

There is a far better way to handle this: Partition off system boot files. 
Even make them read-only and remount to rw to do mods then remount ro again.