JFFS2 access delay

JFFS2 access delay

["David Müller (ELSOFT AG)"]

Hello

While playing around with JFFS2 on a NAND flash on an ARM based board,
i'm facing a strange problem:


First i create a tar file (using BusyBox's builtin tar command) on a
fresh formatted JFFS2 filesytems from a directory containing about 500
1kB files like this:

~ # flash_eraseall -j /dev/mtd/1
Erasing 16 Kibyte @ 1ea8000 -- 24 % complete. Cleanmarker written at
1ea8000.
Skipping bad block at 0x01eac000
Erasing 16 Kibyte @ 7dfc000 -- 99 % complete. Cleanmarker written at
7dfc000.
~ # mount -t jffs2 /dev/mtdblock/1 /mnt/hd/
~ # tar -cf /mnt/hd/t.tar /tmp/test
tar: Removing leading '/' from member names
~ # time ls -l /mnt/hd/
-rw-r--r--    1 root     root       769536 Jan  1 00:23 t.tar
real    0m 0.05s
user    0m 0.00s
sys     0m 0.04s


Everything seems to be fine. But if i unmount and remount the JFFS2
partition, the first "ls" to the JFFS2 takes quite some time:

~ # umount /mnt/hd/
~ # mount -t jffs2 /dev/mtdblock/1 /mnt/hd/
~ # time ls -l /mnt/hd/
-rw-r--r--    1 root     root       769536 Jan  1 00:23 t.tar
real    1m 32.68s
user    0m 0.01s
sys     0m 7.13s


During this delay, "jffs2_gcd_mtd1" is consuming a large amount of CPU
time but the rest of the system seems to be well.


If i don't build the tar file directly on the JFFS2 partition, but just
copy the final file over from another partition, there isn't such a delay:

~ # umount /mnt/hd/
~ # mount -t jffs2 /dev/mtdblock/1 /mnt/hd/
~ # time ls -l /mnt/hd/
-rw-r--r--    1 root     root       769536 Jan  1 00:53 t.tar
real    0m 0.07s
user    0m 0.01s
sys     0m 0.04s


I'm using linux 2.6.11. I also gave the latest MTD CVS code a try, but
with the same result.

Does this ring a bell? Any idea how to cure this behaviour?


Dave

Re: JFFS2 access delay

[Artem B. Bityuckiy]

> Hello
> Everything seems to be fine. But if i unmount and remount the JFFS2
> partition, the first "ls" to the JFFS2 takes quite some time:
...
> 
> During this delay, "jffs2_gcd_mtd1" is consuming a large amount of CPU
> time but the rest of the system seems to be well.
This is normal JFFS2 behaviour (unfortunately). Just after mount JFFS2
starts checking process which consumes resources.

> Does this ring a bell? Any idea how to cure this behaviour?
No. This isn't a bug, this is feature
(http://www.cbttape.org/funny/bug3.jpg).

What is the size of your flash?

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: JFFS2 access delay

["David Müller (ELSOFT AG)"]

Hello

Artem B. Bityuckiy wrote:
>> During this delay, "jffs2_gcd_mtd1" is consuming a large amount of
>> CPU time but the rest of the system seems to be well.

"ls" delay time goes up to over 6 minutes for a tar file containing 1000
files.

> This is normal JFFS2 behaviour (unfortunately). Just after mount
> JFFS2 starts checking process which consumes resources.

This is a little bit of a problem if your system's root file system is
on this partition, blocking the whole boot process :-(

What puzzles me is the fact that the tar file building process
triggers this "weak" point in JFFS2. Tar simply concatenates its input
files together and writes them to the output file (at least this is my
idea of how tar works). So on the file system level, i don't see much
of a difference between a functionality used by "tar" or by "cp". What
is so special about tar?

> What is the size of your flash?

The JFFS2 partition has 126MiB, the whole NAND flash has a size of 128MiB.


Dave

Re: JFFS2 access delay

[Artem B. Bityuckiy]

David Müller (ELSOFT AG) wrote:
> The JFFS2 partition has 126MiB, the whole NAND flash has a size of 128MiB.
The problem with JFFS2 is that is does not scale. 126 MiB is very large 
partition for it. Read 
http://www.linux-mtd.infradead.org/tech/JFFS3design/node3.html for more 
details. JFFS2 was designed for small flashes and works perfectly with them.

BTW, the flash file system for Large-scale flashes is rather challenging 
task.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: JFFS2 access delay

[Jörn Engel]

On Tue, 24 May 2005 14:40:49 +0200, "David Müller (ELSOFT AG)" wrote:
> 
> Does this ring a bell? Any idea how to cure this behaviour?

Works as designed.  If this behaviour is not desired, it's about time
for a redesign...

...which will come within 12 month.  Just not today, so you have to
live with jffs2 for some time.

Jörn

-- 
More computing sins are committed in the name of efficiency (without
necessarily achieving it) than for any other single reason - including
blind stupidity.
-- W. A. Wulf 

Re: JFFS2 access delay

["David Müller (ELSOFT AG)"]

Hello

Jörn Engel wrote:
> Works as designed.  If this behaviour is not desired, it's about time
>  for a redesign...
> 
> ...which will come within 12 month.  Just not today, so you have to 
> live with jffs2 for some time.

Do you know if JFFS3 or Yaffs show a similar behaviour?


Dave

Re: JFFS2 access delay

[Artem B. Bityuckiy]

> Do you know if JFFS3 or Yaffs show a similar behaviour?
> 
JFFS3 doesn't really exist.
I haven't ever tried YAFFS, but Charles said it is OK.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: JFFS2 access delay

[Jörn Engel]

On Wed, 25 May 2005 12:27:49 +0400, Artem B. Bityuckiy wrote:
> 
> > Do you know if JFFS3 or Yaffs show a similar behaviour?
> > 
> JFFS3 doesn't really exist.
> I haven't ever tried YAFFS, but Charles said it is OK.

If you read the design, you notice the same scalability problem JFFS2
suffers from.  Yaffs is maybe 10x or 100x better.  Which means, it
will be just as bad as JFFS2 is today once the flash sizes have grown
by 10x or 100x.

And in exchange it suffers a bunch of other limittions.  Basically,
only use it if you have an embedded device with raw nand flash access.

WRT. flash filesystems, you're currently sitting between a rock and a
hard place.  Traditional disk-based filesystems like ext2 will kill
your flash in a few month or even weeks, but show decent performance.
Dedicated flash filesystems are near-optimal for flash survival and
perform like a snail on an uphill race.

For now, go with JFFS2 or Yaffs (if you have NAND and don't need
compression).

Jörn

-- 
A victorious army first wins and then seeks battle.
-- Sun Tzu