Re: reiser4 plugins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jun 27, 2005, at 22:21:35, Hubert Chan wrote:
On Mon, 27 Jun 2005 18:27:26 -0500, David Masover <[email protected]> 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.)

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.

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

Agreed.  I discuss this more below

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

Absolutely.  On the other hand, that's not to say it can't be improved.


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.

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


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

Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare

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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux