X-Git-Url: http://aleph1.co.uk/gitweb/?a=blobdiff_plain;ds=sidebyside;f=Documentation%2Fyaffs2.html;h=8dd694f38bc99573b98b63cc822722b1c67d2277;hb=1ceac6b8722fe56ebe1b29e6e0dfc0664cbdd2c6;hp=9014465ba399097aa8fa7a64ff0a9899e63e64bd;hpb=d3a46536d1812c81e1c494235ce8f7e25ebb0e1b;p=yaffs%2F.git diff --git a/Documentation/yaffs2.html b/Documentation/yaffs2.html index 9014465..8dd694f 100644 --- a/Documentation/yaffs2.html +++ b/Documentation/yaffs2.html @@ -7,7 +7,7 @@ - +

YAFFS2

@@ -54,19 +54,59 @@ can't use the "discarded" flags in YAFFS2.

  • Since there is no deletion, a resize (shrinking) of a file will still have valid data chunks past the end of file on the NAND. However, we write a new ObjectHeader at the time of the resize, - therefore this shows the shrunken file size.

    + therefore this shows the shrunken file size. The ObjectHeader also + carries information to say that this is a shrink, for some special + handling in the garbage collector.

    +



    +

    This changes erasure slightly:

    This makes erasure & garbage collection more expensive (by adding reads), but remember that ion YAFFS2 we don't need to do page deletions which are much more expensive operations. Thus, all-up YAFFS2 wins.

    +

    Resize Handling

    +

    In YAFFS, soft deletion is ued for everything but resizing +(shrinking) a file which has some particularly ugly cases that can +complicate garbage collection.

    +

    As mentioned before, we write a new ObjectHeader to indicate the +shrinking. However, it is important that this ObjectHeader does not +get destroyed (erased) before the data chunks that were discarded +during the shrink are destroyed (erased). If this precaution is not +taken then it is possible that the deleted chunks might be brought +back to life.

    +

    The modification to the garbage collector is as follows:

    + + +



    +

    +



    +

    Tag structure

    Each chunk in YAFFS2 has the following information:

    @@ -757,12 +797,12 @@ particular:

  • Newer, larger, NAND with 2kB pages can be used in chunks of 2kB. Keeping the relationship of one chunk per page improves robustness and performance (rather than say trying to "fake" - 512byte pages). A block comprises 64x2kB pages.

    + 512byte pages). A block comprises 64x2kB pages.

  • Some devices have 512byte pages, but are arranged as multiple "bit planes" which can be programmed and erased in parallel. For example, the Samsung K9K1G08U0M can support 4 simultaneous operations. YAFFS2 can exploit this by using 2kB chunks - by using groups of 4 pages - one on each bitplane. Virtual blocks + by using groups of 4 pages - one on each bitplane. Virtual blocks would be built which comprise 32x2kB chunks.

    To this end, yaffs_guts is being re-crafted to support arbitrary @@ -781,7 +821,7 @@ to be changed:

    Some of these differences can be absorbed in the yaffs_mtd layer. Some will need to be handles inside the mtd itself.

    -

    $Id: yaffs2.html,v 1.2 2003-01-14 23:15:41 charles Exp $

    +

    $Id: yaffs2.html,v 1.3 2003-09-16 06:48:38 charles Exp $