Re: reiser4 plugins

[Kyle Moffett <mrmacman_g4@mac.com>]

On Jun 27, 2005, at 23:45:00, Hubert Chan wrote:
> On Mon, 27 Jun 2005 22:59:24 -0400, Kyle Moffett  
> <mrmacman_g4@mac.com> said:
> > /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.)

Ok.  Those things should probably be divided up.  Stuff like POSIX
extended attributes and such that have existing interfaces should use
those.  Other types of data should chose other interfaces that make
the most sense for that type of data.  I think that the /meta fs
should probably only be used when the data is generated from the
existing file or directory, and perhaps a few other cases.

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

I agree with the first, but I think that the implementation and usage
confusion will be one of the barriers preventing '...' or metafs merge.

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

Agreed.  On the other hand, perhaps filesystems that support such meta
data should internally assign the appropriate numbering to make it work
nicely.

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

I don't see this occurring often enough to be a major problem, and in
any case inodes are not path-exclusive (think hardlinks).  If they have
the filedescriptor open, however, they could use /proc/$PID/* to figure
out where the file is.

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

Yeah.  I was referring more to calling it "metafs" than "attrfs",
because it seems it would be more than just attributes.

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

Those would be tied to file descriptor (/meta/fd) or filesystem device
ID (/meta/fs/$DEV), and would therefore be accessible from metafs in a
similar way to how filedescriptor path info is available from procfs.

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

Agreed.  On another note, it's nice to see the flamewar has died out
and several technical discussions are taking place on various  
levels :-D.

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/