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

"Giuseppe Bilotta" <[email protected]> Wed, 2 May 2007 14:15:07 +0200
Newsgroups gmane.comp.file-systems.fuse.devel,gmane.comp.file-systems.avfs.user
Message-ID <[email protected]>
On 5/2/07, Miklos Szeredi <[email protected]> wrote:
> [CC'd avf-user as well]

Oh, that was the first thing I looked at, but it seemed that all the
latest archived message on the SF.net site were spam ... which is why
I reverted to the FUSE list for my query :)

> It's definitely not abandoned, Ralf is taking good care of it, and
> does releases once in a while.

That's very nice to know. Since it wasn't even listed in the FUSE
wiki, I was afraid this jewel would be lost :) I've just added an
entry to the wiki, in the ArchiveFileSystem page (I'm not sure it
should be there, though, given its wide scope...), I hope it's all
right.

> The biggest problem with avfs/fuse is I think the lack of the "magic"
> access to archived files in the normal filesystem.  What I mean, is
> that
>
>   ls foobar.zip#/
>
> or
>
>   ls foobar.zip/
>
> should just work, as it used to with the "LD_PRELOAD hack" and later
> the "redir hack".  On a moder linux system this doesn't work any more.
> Progress in linux should not be blamed for this, it is rather that the
> old hacks which made it possible have been slowly cleaned up.  And so
> now we're forced to do this properly, which is not trivial.

Yes, you probably noticed I realized that by the bug report about
trying to compile CODA support with the latest kernels :) I'm
currently working around this limitation with a hand-written script
that given a file creates a symlink to the corresponding directory in
.avfs

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.

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.

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).

A different approach, to be used possibly together with the previous,
at least in the initial deployment stage (i.e. while userspace isn't
still very aware of the virtuality of some mountpoints) would be to
make virtual mountpoints available to direct access, but not
enumerable via standard methods. System calls to enumerate virtual
mountpoints could be added, and some basic userspace program to call
them.

Also, if we only allow directories as virtual mountpoints, since their
content would be marked as being on separate filesystems, it would be
possible to skip them more easily even while userspace doesn't
understand them yet.

BTW, is this mailing list appropriate or should this kind of
discussion be moved to something where it's more on topic?

-- 
Giuseppe "Oblomov" Bilotta

-------------------------------------------------------------------------
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/