[OBORONA-SPAM] Re: inode checkpoints

Josh Boyer jdub at us.ibm.com
Mon Oct 4 09:39:55 EDT 2004


On Mon, 2004-10-04 at 08:26, Artem B. Bityuckiy wrote:
> > 
> > Yes and no.  It makes sense for any flash device that you can't write to
> > the same page multiple times without an erase in between.  NAND is
> > certainly the largest group of such devices.  There are others that have
> > this behavior as well.  See cfi_cmdset_0020.c.
> 
> The original idea of ICPs (inode checkpoint) is to improve JFFS2 
> performance on NAND not because the page can't be written lots of times.
> The NAND flash specific is that there is constant delay when accessing 
> any page.
> 
> For example consider TOSHIBA TC5DxM82A1xxxx 8-bit 256 Mbit NAND flash.
> Page access delay is 25 microsecs.
> Read cycle is 50 nanosecs.
> 
> When you read 3 bytes from this NAND flash and these bytes are situated 
> in one page (consequently), you will spent about 25 microsecs + 50 * 3 
> nanosecs.
> But when you read those 3 bytes from the same NAND flash and these bytes 
> are situated in three different pages, you will spent about 25*3 
> microsecs + 50 * 3 nanosecs.

Yep.

> 
> So, when the inode cache is built, we read node headers from *different 
> pages*. But if there is checkpoint, we read from few pages. This is the 
> main idea.
> 
> But in case of regular file inodes we also save *additional* time since 
> we don't check the *data* CRC for those nodes, which are in 
> checkpoint(s). In case of the directory inode there is no such 
> additional time savings.

I agree that these changes will benefit NAND the most, but they are also
valuable for all flashes.  

Say I have a 16 MiB file on my NOR flash.  When a stat or open is done,
iget is called, which calls readinode, which then goes and reads all the
nodes off of the flash to build up the inode information.  I've seen
that take upwards of 2 seconds, just because of the number of data nodes
that have to be read.

Now, same situation, but I have a checkpoint node out there.  I don't
have to read _all_ the data nodes because the checkpoint gives me a
snapshot of at least some of them, right?

Or maybe I am extending your idea a bit further than what you
intended...

josh





More information about the linux-mtd mailing list