[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