Re: inode checkpoints

["Artem B. Bityuckiy" <abityuckiy@yandex.ru>]

> Can we extend this to be "files with a large amount of nodes"?  I'm
> thinking of the fifo problem here too...
>
:-)
FIFOs, blk/chr dvice files *always have only one valid node at a time* 
(right?). Thus, when building the inode cache, we may only read the node 
with the highest version (which is found by scanning the correspondent 
node_ref list) and read *only* this node. If it is OK (CRC is right), no 
need to read more. If CRC is bad, read the older one...  Checkpoints 
aren't needed, this is *another* improvement...

How about this scheme?

> 
> eCos doesn't have a GC thread IIRC.  Not a big deal in my opinion, but
> others might care :).
> 
> josh
.....
David Woodhouse:
 > I agree that it shouldn't be left to the GC thread alone -- there isn't
 > one on eCos and it's optional on Linux too.

Hmm, true.
Does eCos support threads (I didn't work with it)? If not, the situation 
is more complicated... I want to use thread (low-priority) in order to 
*not affect the system performance much*.

 >We can write out snapshots
 > in the normal course of garbage collection though, when we have
 > obsoleted a node belonging to the inode in question.
> 
I think the checkpoints shouldn't be created by GC (when it is actually 
garbage collecting) because of it will decrease the JFFS2 performance. 
GC is called on some write request when there is no space (excluding the 
situation when it is called in background by the GC thread). This, it is 
bad to load GC by additional work of creating checkpoints since it is 
long enough process....

What do you think?

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