A common VFS and a Common conf-system (Was: namespacing)

[Philip Van Hoof]

On Tue, 2005-03-01 at 12:28 -0500, Sean Middleditch wrote:

> >For the same reasons that microkernels are slow.  I don't think I want to be
> >part of *that* famous argument, so I'll leave it at that :)

> Being honestly curious on this, if you're up to explaining it to me,
> feel free to mail me off list about it.  I'm just not seeing any way
> that going through the kernel makes the implementation more efficient.

I can imagine situations where putting this in the kernel could indeed
speed it up. For example memory caches would speed things up. The kernel
has access to more "already"-cached objects. For example copying the
same source to multiple locations is probably speed-enhanced by caching
the contents of the source-resource (until the resource get changed --
which invalidates such a cache, of course --). I'm not really a
kernel-hacker so I don't know in detail what is and what isn't
cached/speed enhanced.

But slow resources (like network-resources) won't suddenly become
super-fast sources simply because it's happening in the kernel. 

Accessing documents on network-resources will probably be, in userspace,
as fast as any implementation in kernel. I'm guessing smb:// with
gnome-vfs is probably as fast as mounting it using the kernel?

I'm guessing it's very impractical for the kernel, in case of
network-resources, to know whether or not the cache of such an object
needs to be invalidated. I don't think much caching can be done here.

It's the servant who's delivering the resource who gets to decide
whether or not such a cache must become invalidated. Which basically
means asking it or getting informed about it (getting called back about
it), over the network. Which is dog-slow so which is something thats
probably not implemented or must be activated per resource on the
servant. I don't know the smb/nfs protocols in that detail but I'm
pretty sure the ftp and http protocols don't have a specification for
something like that. Simply because you don't stay connected to such a
service (and a browser-cache is probably a lot like it, but I don't
think a VFS should implement something unreliable as a browser-cache
style of caching). 

So for local operations, yeah sure it's faster to do this in the kernel.
But then again, the POSIX read/write/open/close operations (who are used
by the vfs-layer) are already optimised in that aspect by the kernel,
no? So just as Sean, I'm wondering why a VFS-layer in the kernel is
going to be so wonderfully faster than a VFS-layer in userspace?

And a vfs can also do caching in userspace. No? But that might become
tricky and involve file alternation monitors for in case something
non-vfs has altered a file being cached by the vfs --> and thats perhaps
a reason why doing a VFS in the kernel is more convenient. Because the
kernel has more information about "already"-cached objects.

Perhaps duplicating those parts of the VFS that can be speed-enhanced by
putting them in the kernel is an option? But IMHO any such
implementation should also be available in pure userspace. This VFS
should be very cross platform. Imagine it will have to be used on for
example Windows machines someday. Are we prepared to start writing
drivers on for example Windows?



-- 
Philip Van Hoof, Software Developer @ Cronos
home: me at freax dot org
gnome: pvanhoof at gnome dot org
work: philip dot vanhoof at cronos dot be
junk: philip dot vanhoof at gmail dot com
http://www.freax.be, http://www.freax.eu.org