Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: J. Bruce Fields (bfields@fieldses.org)
Date: 12/16/04-02:56:06 PM Z


Date: Thu, 16 Dec 2004 15:56:06 -0500
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-ID: <20041216205606.GE7357@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>

On Thu, Dec 16, 2004 at 11:42:26AM -0800, Gordon Waidhofer wrote:
> The question of NFSV4_{READ|WRITE}_NAMED_ATTRIBUTES
> should be deferred for as long as possible, certainly
> in the near term. Why? Simply because there is unspoken
> discord about what a named attribute is.

I agree about the {READ|WRITE}_NAMED_ATTRIBUTES bits.

> Linux, FreeBSD, et al, have "Extended Attributes".
> The interface, getxattr(), is really like ioctl()
> using a textual name rather than a small integer name.
> Capacity is small and usually (should be) defined
> by the system. Content is non-opaque. Access is
> through get/set style interface.

Under Linux, extended attributes with names beginning with "user." are
entirely up to userspace to manage, and are opaque as far as the kernel
is concerned.  Others (such as "system.posix_acl") may have structure.
I think the upper limit on content is on the order of 64k.

There's some interest in adding a named attribute interface closer to
that of NFSv4's or Solaris's, but not much work done on it yet as far as
I know.

--b.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-02:13:48 AM Z CST