[Yaffs] Re: Mounting behaviour of YAFFS - how it behaves in …

Startseite
Anhänge:
Nachricht
+ (text/plain)
Nachricht löschen
Nachricht beantworten
Autor: Martin Egholm Nielsen
Datum:  
To: yaffs
Betreff: [Yaffs] Re: Mounting behaviour of YAFFS - how it behaves in time compared to JFFS2?
>>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