Re: [AVFS] [fuse-devel] virtual mountpoints (was: AVFS (but not only) + FUSE : access() returns W_OK, but opening r+ fails)

> I suspect the only solution would be to implement some kind of virtual
> mountpoint in the Linux VFS, with hooks to have userspace control it.
> This would allow for example the implementation of many of the
> reiserfs4 claiimed features in a more filesystem-agnostic way.

Yes, something like that.

> The idea I had in mind was something like this: when an app is
> enumerating the entries in a particular directory, the VFS will return
> all the entries 'really' in the directory (as provided by the
> underlying filesystem) and then query all the registered VMPP (Virtual
> MountPoint Providers) for additional entries, passing the directory
> and the list of entries enumerated so far as parameters. Each VMPP
> would then use this information to add more entries, making sure that
> the 'constructed' entries don't exist already.
> 
> These VMPs (Virtual MountPoints) would be handled by the corresponding
> VMPP, and would not necessairly be directories to other filesystems
> (for example, somefile.ext.gz could have a corresponding virtual entry
> somefile.ext which is the gunzipped file content), but I'm not sure
> about this, see below.

The union mount concept could enable such virtual mountpoints:

  http://lkml.org/lkml/2007/4/17/150

But I'm not sure either.  I think I'd prefer a solution where there
are no extra files in the filesystem, but one could interpret files as
directories:

  somefile.txt.gz/extract

and

  foobar.tar.gz/dir/subdir/file

These would be very natural interfaces, without having the filesystem
cluttered with virtual mountpoints.

Of course I don't know how many applications would break due to this
(not many I hope), or how many applications assume that a file with
S_IFREG mode cannot be opened as a directory (probably quite a few).

> I'm not a kernel hacker, but I don't see this as particularly
> difficult to implement code-wise. However, I do realize there are some
> issues when it comes to usage with *some* userspace clients. The
> biggest problem, as I see it, are tar, cp and other similar archiving
> program.
> 
> The most obvious solutiong, which would however require userspace
> support before deployment, is to add some IS_VIRTUAL flag to
> direntries, so that programs would know to skip it in particular
> circumstances (or with appropriate userspace flags).

I'd really prefer if we didn't need _new_ interfaces.  I believe that
even if some applications will need to be modified to be able to use
this feature, the filesystem interface itself shouldn't need to be
modified.

Miklos

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/