Re: reiser4 plugins

[Hubert Chan <hubert@uhoreg.ca>]

On Mon, 27 Jun 2005 18:27:26 -0500, David Masover <ninja@slaphack.com> said:

> Kyle Moffett wrote:
>> I think the '...' is just a bad idea in general, because it breaks
>> tar and such.  An interface like this might be simpler to design and
>> use:
>> 
>> # mkdir /attr
>> # mount -t attrfs attrfs /attr
>> 
>> /attr/fd/$FD_NUM == '...' directory for a filedescriptor
>> /attr/fs/$DEV_NUM/$INODE_NUM == '...' directory for an inode

The most obvious (at least obvious for me) complaint about this is that
the attributes are separate from the file.  (In other words, it's a bit
ugly. ;-) ) So if you want to backup a file, along with all its
(extended) attributes (or substreams, or ... etc. ...), you need to
backup the file, and find the appropriate /attr/fs/$DEV_NUM/$INODE_NUM
and back that up.  If I want to edit an attribute, I need to find
$DEV_NUM and $INODE_NUM (which I have no idea how to do), rather than
just "edit foo/.../extended_attribute".  (Or using your "getattrpath"
command, it would be a two-step process -- run getattrpath, then run
editor -- rather than a one-step process.  Of course, this is only
mildly annoying.)

It also exposes a difference between attributes and regular files.
e.g. can I add attributes to an attribute?  (say, I have a thumbnail
attribute for the file ~/foo, and I want to add a mime-type attribute to
that thumbnail attribute.)  If you want to allow it, you have to be
careful not to run into a big loop generating an infinite number of
inodes in the attrfs. (e.g.
/attr/fs/$(getattrpath /attr/fs/$(getattrpath ~/foo)/thumbnail)/mimetype
-- attrfs shouldn't generate the inode for that until
/attr/fs/$(getattrpath~/foo)/thumbnail is accessed, and maybe not even
then...)

That said, I prefer that interface over xattr or openat.

>> It would be usable from a shell with a simple "getattrpath" command
>> which returns "fs/$DEV_NUM/$INODE_NUM" by stat-ing any given path.

> Still pretty annoying, but maybe a good idea, especially if the shell
> gets extended to support it.  Not sure I like using inode numbers,
> though -- I like the idea of being able to symlink to stuff inside the
> meta-file dir.

The advantage of using inodes rather than pathnames is that it is robust
with respect to file renaming/moving.  It also allows things like
adding attributes to symlinks (since the inode number for a symlink is
different from the inode number for the file that it points to).

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

> Actually, I like this.  Give me some time to let it percolate.

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

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