fragtree method?

fragtree method?

[hinko.kocevar]

Hello all,

We are using JFFS2 fs on toshiba NAND flash. There are several 
partitions defined, but scan time at boot time gets longer every day of 
usage. Eg.  when flash is empty it takes ~10 s to mount 20Mb of flash in 
3 partitions later when there are some files present it takes > 30s and 
increasing.

We have April MTD branch and are currently going for newer version. We 
would also like to know if fragtree method posted by Artem in July [1] 
would be wise to add. If anyone has some experience with it, please, 
post it.

[1] [PATCH] (preliminary) new fragtree build method 24.07.2005

regards,
hinko k

Re: fragtree method?

[Artem B. Bityutskiy]

Hello Hinko,

hinko.kocevar@cetrtapot.si wrote:
> Hello all,
> 
> We are using JFFS2 fs on toshiba NAND flash. There are several 
> partitions defined, but scan time at boot time gets longer every day of 
> usage. Eg.  when flash is empty it takes ~10 s to mount 20Mb of flash in 
> 3 partitions later when there are some files present it takes > 30s and 
> increasing.
The picture you are observing is normal for JFFS2. The more data is in 
your flash, the longer is JFFS2 being mounted. I would shortly explain 
this as follows.

There is no indexing information stored on the flash media. Each JFFS2 
node contains full information about itself, but there is no central 
index. The index is the crucial part of any file system as it is used to 
quickly locate any piece of information (i.e., find all the files kept 
in a directory, find the physical flash address where the files data is 
stored, etc.). In JFFS2, the index is maintained in RAM and takes 
significant amount of it. Roughly speaking, there is a in-RAM data 
structure for each on-flash node.

The in RAM index must be built on each mount. For this reason, JFFS2 
must scan the flash media. And it is logically then the more data you 
have on flash, the longer is JFFS2 mount time and memory consumption. 
Namely, the above 2 characteristics linearly depend on the flash size 
(O(N), N - flash size).

You may also glance at 
http://www.linux-mtd.infradead.org/tech/JFFS3design.pdf for some 
additional info.

So, what you see is the JFFS2's feature. One way to relax that bad 
property is to use the latest JFFS2 with EBS enabled. You'll mount much 
faster. But it is worth noting that this does not radically change the 
situation with JFFS2 as it still stays linearly scalable (O(N)).

> We have April MTD branch and are currently going for newer version. We 
> would also like to know if fragtree method posted by Artem in July [1] 
> would be wise to add. If anyone has some experience with it, please, 
> post it.
It is already in the CVS. And yes, it reduces the backgroung CPU load 
(the checking process) considerably.

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

Re: fragtree method?

[hinko.kocevar]

Artem B. Bityutskiy wrote:
> 
> So, what you see is the JFFS2's feature. One way to relax that bad 
> property is to use the latest JFFS2 with EBS enabled. You'll mount much 
> faster. But it is worth noting that this does not radically change the 
> situation with JFFS2 as it still stays linearly scalable (O(N)).

Thank you for prompt answer. We were aware of the slow-mount-feature of 
JFFS2 but your explaination cleared some stuff for us though.

> 
> It is already in the CVS. And yes, it reduces the backgroung CPU load 
> (the checking process) considerably.

Ah, great. That would explain some of the patch problems I've been 
having while trying to apply the fragtree patch (although it doesn't 
apply cleanly on july CVS checkout either).

Will post comments on using new CVS in respect to the one we were using 
until recently.

regards,
hinko k

Re: fragtree method?

[Artem B. Bityutskiy]

hinko.kocevar@cetrtapot.si wrote:
> Artem B. Bityutskiy wrote:
> Thank you for prompt answer. We were aware of the slow-mount-feature of 
> JFFS2 but your explaination cleared some stuff for us though.
Note, you should enable EBS (eraseblock summary) to mount faster. My 
patch speeds up the checker.

Well, to be more understandable, JFFS2 mount consists of 2 phases:
1. Scan
2. Checking

During the first phase JFFS2 FS is unaccessable. During the second 
phase, it may be read, but writers are blocked until the checking is 
done (checking works in context of the GC tread and only - once just 
after mount). The main "show-stopping" phase is the scanning. EBS 
improves scanning - enable it. My patch improves the second phase and it 
will work by itself as it is already committed.

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