[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Q: JFFS2 RAM requirements (and other questions...)
On Tue, 2004-07-06 at 00:11 +0200, Nitzan Shaked wrote:
> * Regarding RAM usage: while the "degenerate" case you present is indeed
> degenrate, it's still possible. I wouldn't want my embedded system to run
> into this and crash because I don't have enough RAM. So I must plan for the
> worst, and is often done in such systems.
Well actually it's not possible. We'll garbage-collect before we fill
the flash that way, and in doing so we'll merge nodes.
We really ought to keep track of how much space in each eraseblock is
suboptimally used like this (as opposed to just clean or obsolete), and
prioritise blocks with a lot of such nodes for earlier GC.
> (In my FAT implementaion, I can bound the amount of RAM usage analytically,
> and the number is not high at all. I sacrifice some performance this, but
> it's better than the alternative of crashing / not using the file-system at
> run-time in extereme cases).
Perhaps you could consider rescanning the flash each time a file is
opened, rather than keeping all this in memory at once? Other people are
currently looking at checkpointing, so that process can be dramatically
accelerated; it's quite slow at the moment.
> * Regarding NAND drivers: I don't see any reason why ECC / spare area should
> be "mandated". What I do (I being a specific driver for a specific flash)
> with my spare area is none of any other layer's business. (Whether I keep
> ECC there, logical-to-physical mappings, wear leveling counters, etc). I
> understand that it's desireable to have some generic code do this for all
> drivers, but in that case all the driver needs to do is read/write the spare
> area, nothing more -- it (the physical driver) does not actually manage the
> data on the spare area.
That's nice for you, and it's where we started :)
However we also have to handle devices like the DiskOnChip, where the
precise layout of the ECC is mandated by the hardware ECC engine. So we
started allowing slightly more of cross-over between the layers and the
API became slightly more complicated. As long as you can provide a
wrapper around your basic hardware driver which JFFS2 can work with,
that'll be fine.
> In any case I already have these NAND drivers working for my platform, I was
> asking about how hard it would be to plug them into the JFFS2 code given
> that they know how to read and write pages and the spare area. (But don't
> manage them. I also higher layers which do and was wondering whether to plug
> those into JFFS2).
You don't want wear levelling and logical-to-physical mapping going on
underneath JFFS2. All it wants is for someone to decide where to keep
ECC and the small amount of metadata it wants to put in the spare area.
> Anyways... I guess it's time I took a look at the code.
You might do well to also join us on the #mtd IRC channel of
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to firstname.lastname@example.org