is support planned for user.* xattrs?

[Joshua Hoblitt]

On Tue, May 08, 2007 at 11:38:10PM -0400, J. Bruce Fields wrote:
> > So I guess my questions are: Is there any design issue that prevents
> > user xattrs from being implemented in mainline?
> 
> We experimented with the idea a bit and decided that xattrs weren't
> really that much like NFSv4 named attributes, which are more like real
> files (e.g., NFSv4 named attributes can be read from and written to like
> ordinary files, and can have attributes of their own).  The reiserfs
> people were pushing for something like this at one point, and there was
> some discussion of how it might be implemented on the kernel mailing
> list, but it never got very far.

Ah - I had assumed that "named attributes" == xattrs.  

> > Alternatively, is there any one else interested in this functionality?
> 
> I'm told selinux wants named/extended attributes.  Other than that I'm
> not sure what exactly people need them for.

I imagine that selinux would be the largest use case.  Not only just for
sharing binaries between machines but for the NFS mounted root diskless
boot case.  I'd certainly be a user for diskless booting.

My real interest in xattrs is for some in house software that is sort of
like perverted user space file system.  It basically represents a
collection of mounted volumes on the system as a flat namespace and
allows many identical copies of files to be stored on different volumes
(optionally with specified volumed names to allow for data locality
optimizations).  It's functional like a cluster file system it's just a
simple library that provides analogs to open()/close()/etc.  I keep
saying I'll write a fuse interface for it someday.  The difference vs. a
typical cluster filesystem (at least 2 years ago when we started work on
this thing) is the desire to be able to say "I want 5 copies of this
important data to be stored on different nodes in my cluster".

Anyways, to cut a long story short because the file names end up be
mangled and I'd like to stick xattrs on them with the original filename
in case of catastrophic metadata failure (e.g., the master/slave sql
database go boom and the last backup was too far out of date) or
corruption.  I'll probably end up just writing an additional "metadata"
file that contains this information anyways.

Cheers,

-J

--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://linux-nfs.org/pipermail/nfsv4/attachments/20070508/592f1aab/attachment.pgp