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

Martin Egholm Nielsen martin at egholm-nielsen.dk
Mon Jul 25 08:38:03 BST 2005


>>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.

Exactly... However with the recent CVS version, these 9 minutes reduced 
to ~45sec - hence "only" twice of what it takes to read the entire 
flash-device (raw with dd)...

Will YAFFS' worst case scenario be somewhat like the time it takes to 
perform "dd if=/dev/mtd0 of=/dev/null"? (In my sitation ~20 secs)

> 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.
I actually could live without the compression - it's the ECC and 
robustness at powerfailure I'm concerned with...

> 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).
Nice! Is YAFFS2 faster at this?

> 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.
Hopefully not :-)

> 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.
I'm really considering it...

// Martin




More information about the yaffs mailing list