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

RE: jffs2 cpu usage



One of the nice things about NAND (so called serial) flash is
that the sectors are small.  erase and write times are very short
compared to NOR flash, which makes it particularly suited to 
this type of file system.  the other advantage is that NAND flash
is MUCH less expensive than NOR, and that will continue to be the case.

In linux systems, generally speaking, you don't run code out of flash.
If you are really going to use flash as a disk, then NAND flash, which is
intended to be a silicon disk substitute is the way to go.  The cost
savings, especially if you want a lot of flash, is more than enough to
include a small boot rom, eliminating the need for NOR flash.

The downside of NAND flash is that it is not error free - you need
to implement ECC, which is typically done by a controller chip.  however,
if you look at what's involved, it's not that hard, and typical systems
have more than enough horsepower.  Even doing this in software, the 
performance advantage over NOR flash is substantial.

I believe that a JFFS2 with a good native NAND flash driver would be a
major boost to embedded linux systems.  It gets around some of the performance
issues inherant in this type of file system while dramatically lowering cost
per byte.


-----Original Message-----
From: Ross, Lawrence [mailto:Lawrence.Ross@xxxxxxx.com]
Sent: Friday, January 25, 2002 6:14 AM
To: 'David Woodhouse'
Cc: jffs-dev@xxxxxxx.com'; Simon Gittins
Subject: RE: jffs2 cpu usage 


> green@xxxxxxx.au said:
> > If we allow the file system to get full(ish) we regularly see delays
> > of the order of 5 seconds when all we are doing is writes of log
> > entries. What is even more terrifying is that if we do an rm of the
> > offending large file(s) the system goes busy for several 10s of
> > seconds presumably doing lots of nice filesystem housekeeping.
> 
> It's a known problem. We need to make the garbage collection 
> code behave more considerately, by adding more conditional schedule
points.
> --
> dwmw2

Do you know if anyone has any plans to address this issue in the near
future?  We were planning/hoping to use JFFS2 for this type of an
application (logging) where we need both the compression and the journalling
and these types of delays would most likely be unacceptable.  How much work
will be required to address this (can you point me in the right direction)?

Thanks,
Larry

************************************ 
If this email is not intended for you, or you are not responsible for the
delivery of this message to the addressee, please note that this message may
contain ITT Privileged/Proprietary Information.  In such a case, you may not
copy or deliver this message to anyone.  You should destroy this message and
kindly notify the sender by reply email.  Information contained in this
message that does not relate to the business of ITT is neither endorsed by
nor attributable to ITT. 
************************************ 


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

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