Messages in this thread | | | Subject | Re: reiser4 plugins | From | Hubert Chan <> | Date | Mon, 27 Jun 2005 22:21:35 -0400 |
| |
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/
| |