Re: reiser4 plugins

[Hubert Chan <hubert@uhoreg.ca>]

Agree with most of the stuff you wrote.

On Tue, 28 Jun 2005 00:38:38 -0400, Kyle Moffett <mrmacman_g4@mac.com> said:

> On Jun 27, 2005, at 23:45:00, Hubert Chan wrote:

>> I think for most people on the reiser-fs list, the '...' directory
>> represents an interface to many things including
>> - automatic aggregating/tar/untar/compress
>> - a different interface to stat data
>> - adding extended attributes/substreams/acls/etc.
>> - anything else you might imagine

> Ok.  Those things should probably be divided up.  Stuff like POSIX
> extended attributes and such that have existing interfaces should use
> those.

One of the claimed advantages of the '...' interface is that everything
is editable as a file.  So if someone wanted to edit the description
extended attribute for foo.txt, he would just run
"[editor] foo.txt/.../description" (or
"[editor] /meta/fs/$(getattrpath foo.txt)/description"), instead of
needing to use some special purpose editor.  It works well for things
like being able to use Gimp to edit a thumbnail or icon attribute.

Of course, it shouldn't be too hard to provide both interfaces, as long
as you get locking and caching right...

The Reiser4 file-as-dir interface is also supposed to be more flexible
than POSIX extended attributes.  For example adding attributes to
attributes (e.g. adding a mimetype attribute to a thumbnail attribute).
The point of it is to present many different things (extended
attributes, file manipulation magic like automatic compress, etc.)
through a single interface that everyone knows how to use (i.e. regular
files) so that people can use regular programs to edit or manipulate
them.

The inspiration, I think, was the MacOS X/NeXTSTEP bundle format.  For
example, MacOS X/NeXTSTEP .app file is actually a directory that behaves
much like an executable file (double-clicking a .app file in the Finder
launches the application, instead of opening the directory).  However,
it is in reality a directory that contains many things that could be
thought of as extended attributes (such as the application icon,
information about the application, etc.).  Since the application icon is
a real file, it can be edited by normal graphics editors (not like
Windows programs, where you need a special icon editor).  And since it's
inside the .app directory, it's attached to the application (not like
Linux, where the program is in /usr/bin, and the icon is in
/usr/share/pixmaps), so it makes package management easier (to delete an
application, just delete the .app file -- don't need to look in
/usr/share/pixmaps for the icon and delete it).

> Other types of data should chose other interfaces that make the most
> sense for that type of data.  I think that the /meta fs should
> probably only be used when the data is generated from the existing
> file or directory, and perhaps a few other cases.

[...]

>> One other minor annoyance is it isn't easy to go backwards from the
>> ... directory to the file.  e.g. if I have a symlink that points to
>> /attr/fs/2/92036, I don't know what file's attributes that refers to.
>> Hopefully I'm sane enough to give the symlink a descriptive enough
>> name...

> I don't see this occurring often enough to be a major problem,

I don't see that this should be a major problem either, but I thought it
was worth bringing up.

> and in any case inodes are not path-exclusive (think hardlinks).  If
> they have the filedescriptor open, however, they could use
> /proc/$PID/* to figure out where the file is.

Although I guess if they have a file descriptor open, they probably have
the original filename lying around somewhere...

[...]

> On another note, it's nice to see the flamewar has died out and
> several technical discussions are taking place on various levels :-D.

Agreed! :-D

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/