lkml.org 
[lkml]   [1996]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectFile system daemon/thread
From
Date
Kai Henningsen writes:
> It might even be a good idea to only add the hash structures once the
> directories grow over a certain size. Note I have that all the
> *information* in one sequential file, just like current Unix directories.
>
> If it's done that way, I'd say that the directory should be larger than,
> say, two buckets before we add hashing - maybe even more. If we can't
> reduce disk accesses, there's not much point in the overhead, is there?

How about: a kernel thread/kerneld-like daemon is informed of all
directory changes. It could change directory structure from list
to hash/B+-tree or whatever as it grows.

What I'd also like to see is low priority kernel thread/kerneld-like
defragmenter. Current stuff is ugly, you duplicate many kernel
functions and the FS has to be offline, when all you need is ability
to lock a directory/file/block, move it, update references and unlock.

Also, in-kernel fsck could first lock the whole FS and then gradually
release locking on the parts it has verified. On the other hand,
the current userland version works nicely, thank you. But for
some really massive and time-critical systems?

-Topi

G? d- s++:- a- C++ ULS++++$ P++$ L++>+++ E W+ N !o K? !w !O !M !V PS+
PE++ Y+ PGP++ t+ 5? X !R tv@ b++ DI++ D+ G+ e+++ h--->h---- r+++ y?



\
 
 \ /
  Last update: 2005-03-22 13:37    [from the cache]
©2003-2011 Jasper Spaans