Re: reiser4 plugins

[Hubert Chan <hubert@uhoreg.ca>]

On Tue, 28 Jun 2005 15:59:03 -0400, Kyle Moffett <mrmacman_g4@mac.com> said:

> On Jun 28, 2005, at 13:51:04, Hubert Chan wrote:

>>  I don't know if VFS is the right place for it, but I agree that it
>> would be good to make it accessible to all filesystems.

> That's somewhat of a contradiction in terms.  The whole point of the
> VFS is to hold all of the things that multiple filesystems want to
> share :-D.

VFS provides a common interface to the filesystem.  I don't think metafs
needs any VFS changes.  It may be able to get by without making changes
to the VFS, and if so, it shouldn't touch the VFS.  It should just be
its own separate filesystem.

I imagine most of it could be implemented by a FUSE filesystem.

> Personally, I think that the multiple views is a good thing.  I like
> being able to "cd /Applications/Games/UnrealTournament2004.app/System"
> and mess with my game files, while double-clicking it in the Finder
> just starts it so I can get on with owning my friends :-D.

Of course.  With file-as-dir, you can "cd /usr/games/tetris/..." and
mess with the game files, or you can run "/usr/games/tetris" and get on
with ... stacking blocks.  The advantage of doing it in the kernel is
that you don't need extra support from the applications (or GnomeVFS or
KDE).  So typing "/usr/games/tetris" from the command prompt does the
same thing as double-clicking it in the file manager.  Of course, this
change does require file managers to understand default actions when
it's ambiguous what to do on a double-click -- but MacOS X has that too,
in the form of the "Open as Folder" option (or whatever it's called).

>> Another problem is that it only works with bundle files.  e.g. I
>> can't add an icon to a regular txt file.  Tiger now supports xattrs,
>> which you could use for that functionality, but then we run into the
>> problem again of not being able to edit it with regular applications.

> Maybe we just need better regular applications?

You mean patch them all so that they understand and can edit
xattr/substreams/etc.?  The file-as-dir interface is meant to avoid
having to do that.  metafs also avoids having to patch all the
applications by exposing them as regular files.

The example you give below isn't a new VFS API.  It's metafs exposing
xattrs/substreams/etc. through the regular file interface.  (Perhaps
we're just using different terminology.)

> I think that for the icon case, for the Samba/streams case, and for
> many others I'm probably forgetting, we should try to come up with a
> new "data-stream" VFS API, so that the icon data and other larger
> quantities can be stored in a filesystem without much effort.  Such a
> layer could even be bridged onto existing filesystems via a
> VFS-wrapper bind-mount:

> # mount -t reiser4 /dev/hda1 /mnt1

> # mount -t ext3 /dev/hda2 /mnt2

> # cat $(metapath /mnt1/foo)/streams/description
> Some random file

> # cat $(metapath /mnt2/foo)/streams/description
> cat: Unsupported operation

> # mount -t none -o bind,streamify /mnt2 /mnt3

> # cat $(metapath /mnt3/foo)/streams/description
> Another random file

> Such a wrapper interface might use the directory '...' to store files
> on the underlying filesystem, but I don't think that the meta
> interface itself should use those directories.

Agreed.

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.