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

Sean Middleditch elanthis at awesomeplay.com
Tue Mar 1 19:28:09 EET 2005


On Tue, 2005-03-01 at 12:10 -0500, Avery Pennarun wrote:
>On Tue, Mar 01, 2005 at 11:43:58AM -0500, Sean Middleditch wrote:
>
>> >> Unfortunately, it's Linux only, and has an incredibly brain-dead design
>> >> where you have to utilize "round-trips" through the kernel for
>> >> something that essentially happens entirely in user-space,
>> >
>> >This is not entirely true: thanks to some contributions by my company,
>> >FUSE has extensions that allow the kernel to *cache* your stuff in the
>> >normal page cache, so after the first access, files can be retrieved as
>> >quickly as from a normal filesystem, even across processes, and with a
>> >high level of reliability.  That's a very big advantage that you will
>> >simply never achieve in a 100% userspace solution.
>> 
>> Why can't it be done in userspace?
>
>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.

>
>If all you're doing is opening a word document, I suppose nobody cares how
>slow it is (which is why kioslave and gnome-vfs, both awfully slow systems
>compared to the kernel, are accepted and useful).  But please don't ask me
>to compile my openoffice source tree on such a filesystem.

That wouldn't even be possible, unless you rewrote GCC to use the
Desktop VFS library.  ;-)

You're right in that this really isn't intended for general file access,
but for Desktop access patterns.  FUSE is probably a great solution for
the former case, but due to its many limitations (the absolute biggest
being portability) we really do need something else like Desktop VFS.

>
>Have fun,
>
>Avery
>
-- 
Sean Middleditch <elanthis at awesomeplay.com>




More information about the xdg mailing list