[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q: JFFS2 RAM requirements (and other questions...)

Thanks David and Alan for answering.

* Regarding the license: thanks David for pointing that out. It actually
looks much better (from my company's pov, I myself would gladly share!)

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

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

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

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

Anyways... I guess it's time I took a look at the code.

Thanks again all,

I guess it's time
----- Original Message ----- 
From: "David Woodhouse" <dwmw2@xxxxxxx.org>
To: "Nitzan Shaked" <calius@xxxxxxx.il>
Cc: <jffs-dev@xxxxxxx.com>
Sent: Monday, July 05, 2004 12:00 PM
Subject: Re: Q: JFFS2 RAM requirements (and other questions...)

> On Sat, 2004-07-03 at 15:41 +0200, Nitzan Shaked wrote:
> > Hello
> >
> > I am considering to use JFFS2 in my embedded system, and was hoping you
> > could save me a week's worth of trouble by answering some order-0
> >
> > 1) I have read the PDF and other introductry material, and I understand
> > for each file a list of nodes in maintained in RAM. For a 32MB
> > containing "your average stuff" (MP3, MIDI, JPG, no code) -- what would
> > say is the RAM requirement ? Is there a way to bound this number?
> It's not so useful to give a theoretical upper bound. That would be the
> degenerate case where you wrote all the files in single-byte chunks, so
> each byte of data has a 68-byte node header on the medium, and a 16-byte
> 'struct jffs2_raw_node_ref' in RAM. In practice, that would get
> garbage-collected and the data would tend to get coalesced into 4KiB
> chunks.
> You can try this on Linux. Make a 'mtdram' device of the appropriate
> size and eraseblock size, fill it with your sample workload. Look in
> /proc/slabinfo to see how many of the JFFS2 data structures are present.
> The jffs2_raw_node_ref is the one which is present at all times while
> the file system is mounted. jffs2_full_* are present only when files are
> being used (well, actually when they're in the inode cache in Linux).
> > 2) Linux- and NAND support: I understand that under the linux-mtd NAND
> > support is not finalized ("nearing production quality"). Still, my
> > does not use linux at all. If I use JFFS2 it will be on a proprietary
> > kernel (no processes, just "threads"), and I will need to port it. So:
> > 2.1) Has this been done before?
> Not for NAND. JFFS2 on NOR is already working on eCos -- the Linuxisms
> in the original code have already been eliminated.
> If looking at the eCos code for inspiration though -- be aware that much
> of it predates the cleaning up of the core JFFS2 code, so it looks a
> _lot_ more like a 'Linux VFS emulation layer' code than it now needs to.
> I've gone through it doing things like changing 'struct inode' to
> 'struct _inode' to make the point that it's not the same as Linux and no
> longer used by core code, but nobody on the eCos side has yet cleaned it
> up.
> > 2.2) Given that I do not use Linux -- how hard will it be to add NAND
> > support?
> The NAND support isn't used on eCos yet. There's a tighter coupling
> between JFFS2 and the OS flash drivers for NAND, because of details
> about how we handle bad blocks, the spare area, etc. But NAND support
> shouldn't be _too_ hard to extend to non-Linux platforms.
> -- 
> dwmw2

To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com