Re: reiser4 plugins

[Hubert Chan <hubert@uhoreg.ca>]

On Mon, 27 Jun 2005 22:59:24 -0400, Kyle Moffett <mrmacman_g4@mac.com> said:

> On Jun 27, 2005, at 22:21:35, Hubert Chan wrote:
>> On Mon, 27 Jun 2005 18:27:26 -0500, David Masover
>> <ninja@slaphack.com> said:
>>> Kyle Moffett wrote:

[...]

>>>> /attr/fd/$FD_NUM == '...' directory for a filedescriptor
>>>> /attr/fs/$DEV_NUM/$INODE_NUM == '...' directory for an inode

[...]

> These are not really "attributes" so much as they are "metadata", for
> example, a "contents" subdirectory, if one existed, would be based on
> the original file, and therefore non-unique, but would be looked up
> based on information about the original file.

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
(I think this is your understanding too?  Just double-checking.)
So some of that stuff would be separate from the file.  (Separate in the
sense that it's not generated from the file's binary data.)

Personally, I don't like it all being in one directory, but it's not
that important.

>> You can still symlink.  It just takes a little more effort to figure
>> out what $DEV_NUM/$INODE_NUM to use.

> Also, unlike a symlink, if the path doesn't change and the file does,
> it will break, also, if the file is removed and another created
> elsewhere, it will be redirected improperly.  Perhaps a new symlink
> syntax is needed to allow attribute specification (Ick, more changes
> :-\).

I think those breakages are acceptable.  (IMHO) In other words, I think
it would not occur very often without the user being aware of it, and
should very rarely result in catastrophic effects.

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

>>> Hans, thoughts?  Seems to be namespace fragmentation, but seems
>>> usable, less breakage, and so on.  And should it be /attr or /meta?
>>  For the mount point, it doesn't matter; it's up to the user.  It's
>> the attrfs or metafs or ???fs that matters (but which will greatly
>> influence whether people user /attr or /meta).

> "meta" seems the more descriptive name.  There should also probably be
> a somewhat standardized location for this, such that programs can
> locate it without much trouble.

Agreed.  Ultimately, it's the user's decision where to put it, but
probably 99.99999% of all people will put it in the same place.  Just
like you could put procfs or sysfs somewhere other than /proc or /sys if
you really wanted to, but nobody does that.

> This mechanism would be usable from all FSs, and could be built into
> the VFS.  Also, it would allow one to access the meta data of meta
> data (if supported by the filesystem, and possibly only through the
> file descriptor lookup, due to numbering limitations.)

One other issue is that the attrfs/metafs needs to communicate with the
other filesystem somehow.  It needs to know if the filesystem can handle
storing of extended attributes/substreams/etc. so that it knows whether
or not to allow those interfaces.  In my
/attr/fs/$(getattrpath /attr/fs/$(getattrpath ~/foo)/thumbnail)/mimetype
example, it needs to be smart enough to store that in ~/foo's
filesystem.  etc.

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