Messages in this thread |  | | Subject | File system daemon/thread | From | Topi Miettinen <> | Date | Fri, 09 Aug 1996 15:34:28 +0300 |
| |
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?
|  |