JFFS2 access delay
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
Quoted 3 lines
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:
...
Quoted 3 lines
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.
Quoted 1 line
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?
Signature · 3 lines
Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia.
Hello
Quoted 2 lines · Artem B. Bityuckiy
Quoted 2 lines
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.
Quoted 2 lines
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?
Quoted 1 line
What is the size of your flash?
The JFFS2 partition has 126MiB, the whole NAND flash has a size of 128MiB.
Dave
Quoted 1 line · David Müller (ELSOFT AG)
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.
Signature · 3 lines
Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia.
Quoted 2 lines · David Müller (ELSOFT AG)
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
Signature · 4 lines
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
Hello
Quoted 5 lines · Jörn Engel
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
Quoted 2 lines
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.
Signature · 3 lines
Best Regards, Artem B. Bityuckiy, St.-Petersburg, Russia.
Quoted 5 lines · Artem B. Bityuckiy
Quoted 3 lines
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
Signature · 2 lines
A victorious army first wins and then seeks battle. -- Sun Tzu