A virtual filesystem standard

[Alexander Larsson]

On Thu, 2003-09-18 at 11:12, Vincent Wagelaar wrote:
> On Thursday 18 September 2003 08:51, Alexander Larsson wrote:
> > On Thu, 2003-09-18 at 02:15, Vincent Wagelaar wrote:
> > > On Tuesday 09 September 2003 15:50, George Staikos wrote:
> > > > On Tuesday 09 September 2003 03:29, Alexander Larsson wrote:
> > > > > On Mon, 2003-09-08 at 16:53, Owen Taylor wrote:
> > > > > > What would be of extrodinary value, I think, would be a writeup of
> > > > > >
> > > > > >  - What works well with KIO
> > > > > >  - What doesn't work / requires hacks
> > > > > >  - How it could have been done better
> > > > > >
> > > > > > I can try to get someone familiar with gnome-vfs (maybe Alex
> > > > > > Larsson) to do the same for that.
> > > > >
> > > > > Yes, this would be interesting. I'll try to find time to write it up.
> > > >
> > > >   Hopefully Waldo and/or David can help and we can do the same.  I
> > > > think it's quite important to plan this out properly before diving in
> > > > head-first.
> > >
> > > Maybe another idea...
> > >
> > > For Linux there exist atm two implementations of a virtual filesystem
> > > kernel module:
> > > Lufs (http://lufs.sourceforge.net/lufs/) and
> > > Fuse (http://sourceforge.net/projects/avf).
> > > Wouldn't this be an idea (at least for Linux, don't know if other os's
> > > have something similar).
> > >
> > > Instead of using smb:// thumbnails:// ftp://host you would simply map it
> > > to: $HOME/vfs/smb and $HOME/vfs/thumbnails $HOME/vfs/ftp/host etc. Or
> > > $HOME/ Desktop. The biggest advantage is that all programs work would
> > > work out of the box, instead of requiring yet another library.
> >
> > There are all sorts of problems with this. Permission issues (need root
> > to mount), kernel stability issues, no standard async i/o API, not
> > portable to all unixes, no good way to handle authentication, etc.
> 
> Smbmount is also suid root (at least on debian). why would we need async io, 
> the current vfs implementations aren't performance monsters either. fuse has 
> limited access to the mounts to the user that has actually mounted it.

Gnome-vfs has asynchronous I/O support, and any replacement needs to
handle that. Its not about performance, its about not blocking the UI.
Its possible to layer this over a blocking system using threads, but
care has to be taken to get things right (enabling cancellation for
instance).

> i would guess that stability would be greater because most code is outside the 
> kernel?

Yeah.

> > Personally i think kernel handling for this is just a bad idea. Fuse is
> > not a kernel thing. Its a LD_PRELOAD thing. I'm even more strongly
> > agains that, since it makes all apps slower (talk to uli about
> > LD_PRELOAD sometime) and breaks the semantics of real system calls.
> 
> Huh, please reread the website. there are 2 projects. one is fuse (kernel 
> module) and another, avf, that is using the coda filesystem (and an optional 
> ld_preload version for e.g. solaris). 

I just followed the Fuse link to http://www.inf.bme.hu/~mszeredi/avfs/
which mentions LD_PRELOAD. I guess i jumped to conclusion. Anyway, a
linux-only system isn't interesting at all for the Gnome project.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a time-tossed flyboy cat burglar haunted by memories of 'Nam. She's an 
enchanted junkie soap star from aristocratic European stock. They fight crime!