lee@sq.sq.com (Liam R. E. Quin) (03/17/91)
No, lightweight files aren't ones with more 0's than 1's....
I've thought off an on for a while about this...
I often seem to end up writing code that duplicates kernel functionality.
For example, when writing an editor or database, one has to write buffer
mangement software. Now, mmap() means that I can get the kernel to read
the file when it wants to (with a loss in synchronous error handling).
Suppose I want to write a database that keeps entries (conceptually) in
linked lists of blocks. The last block in each entry will generally be
of a smaller size, to reduce internal fragmentation.
Hmm, sounds just like the BSD filesystem.
But I don't want to have to use an i-node for each entry, with the associated
namei() name-to-inode translation on lookup. I don't even want to sacrifice
that much space, since I don't need to keep as much info as an inode does.
Well, I could write my own file system code. But that isn't very portable,
and I don't see many people installing a public domain (or other) package
that says "now build the following code into /vmunix" in the INSTALL file!
So I'm looking for a comprimise.
I am quite willing to implement something on top of the existing filesystem,
just as I've done in the past, but it seems a shame to me that I'll be
duplicating chunks of block- and buffer- management code, cache handling
code, i/o code, ..... sigh.
Ideas?
Lee
--
Liam R. E. Quin, lee@sq.com, SoftQuad Inc., Toronto, +1 (416) 963-8337
`A wrong that cannot be repaired must be transcended'
Ursula K. Le Guin, in _Tehanu_