Re: reiser4 plugins

[Kyle Moffett <mrmacman_g4@mac.com>]

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