On Wed, 2012-11-14 at 10:20 -0500, Matt W. Benjamin wrote:
> Actually, that reasoning sounds a little like a concession that the feature should be blocked precisely because it may be tremendously popular (useful). I don't think the argument that proplists can be the building blocks for new system--but also application--functionality is a good argument against them.
What feature? The xattr interface? Before declaring it a major success
story, you might want to consider that it has been implemented on
several major Linux filesystems for more that 10 years, yet is used by
only a handful of (non-portable) applications.
The main use-cases that I'm aware of are:
* Storage for ACLs.
* Storage for security labels.
* Samba uses xattrs for storing various per-file control
structures, when xattrs are supported by the underlying
filesystem.
* Storage for file search tags for use by programs such as
"beagle" and "tracker".
Both ACLs and security labels are already covered by the NFS protocol.
We don't need or want an xattr protocol to solve those problems.
As for Samba, it works fine on filesystems that don't have xattrs as far
as I know. Using it to re-export an NFS partition to CIFS is a dubious
practice, but is not an xattr-related problem.
So that leaves the "beagle" and "tracker" use case, where the xattr
usage for storing tags could easily be replaced by a database (and
usually is in equivalent portable software). Most people who want to do
serious work on their systems tend to turn off beagle and tracker anyway
since they are notorious cpu hogs.
> ----- "Trond Myklebust" <Trond.Myklebust@xxxxxxxxxx> wrote:
>
> > On Wed, 2012-11-14 at 11:47 +0100, Tigran Mkrtchyan wrote:
> > > That's bad news.... Currently we use 'magic files' to set/get user
> > > specific metadata like number of events, space reservation and
> > > different file retention policies. The hope was that all could be
> > done
> > > with named attributes.
> > >
> > > Tigran.
> > >
> >
> > The setting and querying of retention policies is already covered in
> > the
> > NFSv4.1 protocol without any need for any additions. Space
> > reservation
> > is already covered in NFSv4.2 (as are security labels - another
> > common
> > hobby-horse for xattr advocates). Why don't you implement those
> > instead
> > of wishing for a completely different way of doing the same thing?
> >
> > Your argument demonstrates precisely why we should never do xattrs
> > over
> > NFS. It makes it way too easy to go off and invent your own private
> > and
> > non-standard protocol for doing ioctl()-like RPC calls.
> >
> > > On Tue, Nov 13, 2012 at 8:54 AM, DENIEL Philippe
> > > <philippe.deniel@xxxxxx> wrote:
> > > A few years ago, SGI tried to promote "NFS3 XATTR", an
> > > extension to NFSv3 to add xattr support. It roughly added 3
> > > functions to the protocol (GETXATTR, SETXATTR, LISTXATTR),
> > in
> > > a similar way as what 9p.2000L does. Nothing but IRIX had
> > this
> > > NFSv3 feature. As far as I know, it remained quite exotic
> > and
> > > stayed a SGI's thing.
> > >
> > > Philippe
> > >
> > > Matt W. Benjamin a écrit :
> > >
> > > Can you restate reasoning why it will never do so,
> > and
> > > whether this is the same as saying it will never
> > > implement named attributes?
> > >
> > > Thanks,
> > >
> > > Matt
> > >
> > > ----- "Trond Myklebust"
> > <Trond.Myklebust@xxxxxxxxxx>
> > > wrote:
> > >
> > >
> > > No. We will never support xattrs over NFS.
> > >
> > >
> > > -----Original Message-----
> > > From:
> > linux-nfs-owner@xxxxxxxxxxxxxxx
> > > [mailto:linux-nfs-
> > > owner@xxxxxxxxxxxxxxx] On Behalf Of
> > > Tomasz Chmielewski
> > > Sent: Monday, November 12, 2012
> > 10:14
> > > AM
> > > To: linux-nfs@xxxxxxxxxxxxxxx
> > > Subject: xattr support in NFS?
> > >
> > > Does Linux support xattr in NFS?
> > >
> > > IF tries using it in both NFS3 and
> > > NFS4 under Debian Lenny (2.6.32,
> > >
> > > both
> > >
> > > server and client), without
> > success.
> > >
> > > # setfattr -n user.comment -v "this
> > is
> > > a comment" /mnt/nfs
> > > setfattr: /mnt/nfs: Operation not
> > > supported
> > >
> > >
> > > --
> > > Tomasz Chmielewski
> > > http://blog.wpkg.org
> > > --
> > > To unsubscribe from this list: send
> > > the line "unsubscribe linux-nfs"
> > >
> > > in the
> > >
> > > body of a message to
> > > majordomo@xxxxxxxxxxxxxxx More
> > > majordomo info
> > >
> > > at
> > >
> > >
> > http://vger.kernel.org/majordomo-info.html
> > >
> > > N�����r��y���b�X��ǧv�^�){.n�
> > > +����{���"��^n�r���z���h����&���G���h�(�階
<> > �ݢj"���m�����z�ޖ���f���h���~�m�
> > >
> > >
> > >
> > >
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe
> > > linux-nfs" in
> > > the body of a message to majordomo@xxxxxxxxxxxxxxx
> > > More majordomo info at
> > > http://vger.kernel.org/majordomo-info.html
> > >
> > >
> > >
> >
> > --
> > Trond Myklebust
> > Linux NFS client maintainer
> >
> > NetApp
> > Trond.Myklebust@xxxxxxxxxx
> > www.netapp.com
> > N�����r��y���b�X��ǧv�^�){.n�+����{���"��^n�r���z���h����&���G���h�(�階�ݢj"���m�����z�ޖ���f���h���~�m�
>
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
