Re: silent semantic changes with reiser4

Spam
2004-09-06T16:15:21Z

>> Plugins were just another thing that could extend the functionality
>> of these streams and meta data. Reiser4 has a plugin architecture,
>> although not yet any run-time support for loading them. Is this so
>> bad that we have to prevent it?

> Take an example: "expose a tar-file as streams below the file" which
> as been suggested here is IMNSHO plain silly. I'm not saying anything
> about mounting a tar file via userfs somewhere else in the file
> system, that is quite ok, but trying to mount it on top of the same
> file which suddenly and automagically turns into a sort-of-directory
> breaks too many thing. Let your file manager do the choice instead,
> based on the users preferences. For example, with a tar.gz-file, I'd
> like to have a choice of "open file as a seekable file" which would
> do:

> mount -t userfs -o driver=gunzip foo.tar.gz /tmp/xyzzy

Where is the difference? Both would be handled by a specific driver
or module and export the same semantics (files+dirs) with permissions
etc to the user. With your idea you still would need the userfs
kernel module, and with "magic plugins", as you said, you will need a
vfs/reiser4 kernel plugin.

> Then I can work with /tmp/xyzzy as a normal file (maybe even with
> write access if the userfs driver can handle this). Another choice in
> the same file manager would be "open file as a directory" which would
> mount the same file in _another place_ as a directory, and I can even
> have different views of the same file mounted at the same time. With
> the named streams junk that have been suggested here, having two
> different views would be impossible.

> Sure, we could say that we add another level of indirection to the
> named streams, so that we specify the driver as the first component of
> te magic file-as-directory, i.e. foo.tar.gz/ungzipped would refer to
> the ungzipped stream and foo.tar.gz/ungzipped-and-untarred would show
> the tar file as a directory, but really, this isn't any more useful
> than doing a userfs mount. The userfs mount does not break existing
> semantics (anymore than mount -o loop does today), and it will work
> with the existing infrastructure in the linux kernel. The only
> advantage of files-as-directories with magic plugins in the kernel is
> that one can look at it and say "look, how neat, the filenames look
> almost the same".

No there are _usability_ differences. I cirtanly do not want to
mount lots of files with mount -t userfs, just to see extra
meta-data that I want to quickly be able to use. And it also
wouldn't work generically (searchable) with tools like find, grep,
etc either.

~S

> /Christer