[Yaffs] Mounting behaviour of YAFFS - how it behaves in time compared to JFFS2?

[Charles Manning]

On Saturday 23 July 2005 03:03, Martin Egholm Nielsen wrote:
> Hi there,
>
> Here's question related to my JFFS2 problems (posted on the MTD-list).
>
> The situation: The mount times of my 32 megs JFFS2 device suddenly
> increased from seconds to (roughly) 9 minutes, after having written some
> files to the device.
> The explanation of this is, according to David Woodhouse's best guess,
> that the garbage collector uses all this time "for building up the
> node tree for every inode after mounting".
> The problem stems (I've been told) from the fact that I have been
> performing "big-file-gymnastics" (11 megs uncompressed - ~3 megs
> compressed) on the device. Possibly along with some small-file actions
> inbetween (?)...
>
> Now my question: Can YAFFS (1&2?) be provoked into showing similar
> "unfortunate" behaviour, or is it handled in another way?

When I originally evaluated JFFS2, before proposing YAFFS, I identified a few 
areas of concern wrt running JFFS2 on NAND. One of those was how its garbage 
collection strategy would scale to large files and large NAND partitions - 
which seems to be the problem you are running into here.

From my (limitied) understanding of JFFS2, the way the files are created and 
extended, as well as the use of compression, can make garbage collection a 
messy business - both costly and unpredictable (in terms of time).

YAFFS does not use compression and has a very clean and simple overwrite and 
garbage collection model. This makes YAFFS garbage collection and scanning a 
lot more predictable and cheaper.

During mount, both YAFFS and JFFS2 rebuild trees by scanning. YAFFS "cheats" 
by using the spare/oob area as a place to store tags and by using fixed size 
chunks. This makes YAFFS scanning pretty fast. (Or course it could be made 
faster still by saving the state as big binary blobs).

The goal in YAFFS is to provide a general purpose file system, as appropriate 
for the more sophisticated software models we see in modern embedded/mobile 
applications. I don't think JFFS2 really shares that goal. For instance, 
YAFFS supports memory mapped file writing (probably the most nasty interface 
when it comes to rewriting etc), whereas JFFS2 does not (well didn't last 
time I checked).

YAFFS is well proven on large devices and ships on a few systems using 
512Mbytes or greater.

Now clearly a full YAFFS system will take longer to mount than an empty one, 
but I don't think it will every get anywhere near as nasty as the case you 
mention above.

BTW: I'm not knocking JFFS2 here, I think it definitely has its place where 
space is very limited. The transition point is probably around 16MB, 
depending of course on application needs.

-- Charles