Russell Coker wrote:
> One thing I have considered doing if I got a large amount of spare time
> (IE something that'll never happen) is to investigate getting the
> user-mode-linux code and taking the block IO part to make file systems
> run in user-space as a database interface. For something like a large
> squid box it might get a performance gain to have small operations
> (directory lookups) take place in user-land rather than have a system
> call for each one.
If you want a user-space implementation it is probably easier to start
from scratch than to try to use the kernel API's. Also, Squid has a
quite simple interface where you can user-space implementations in if
you have one.
However, for Squid we are also interested in seeing a separate store
(preferably kernel). This to simplify scalability design and recovery.
Also, I strongly suspect that for most applications who would benefit
from such a move the UNIX filesystem API is not a suitable
startingpoint. This is certainly true for Squid.
- limited name space
- hart to have any secondary indexes. File names are too loosely
coupled with the object.
- lack of transactions
- very clumsy atomic operations
- poor memory usage
- all synchronous
> Also it could potentially have some benefits for debugging. I thought
> that combining the above with a LD_PRELOAD library to take over the
> read/write/open/etc library calls could allow an application to think
> it's using regular files while it's really accessing a user-land process
> and talking over named pipes. Then you could test out a new version of a
> file system without risking crashing your machine!
user-mode-linux is already a quite neat framework for testing and
debugging filesystems and other generic kernel components (basically
anything except hardware drivers).
--
Henrik Nordstrom
Squid Hacker
