Subject: [nfsv4] Named Attributes

From: Mike Mackovitch <[email-masked]>
Date: Thu, 3 Sep 2009 10:14:29 -0700

I'm whipping up support for Named Attributes in the Mac OS X NFSv4(.0)
client so we can store all the extra "Mac goop" the OS likes to store
in the file system natively instead of having the VFS throw the goop
in an ugly "._" file.

One problem I have is that I need to determine - at mount time - if the
server supports named attributes so I can set a flag that says "natively
supported" vs. "must use ._ files".

So, how can a client determine if a server supports named attributes?

My first thought was that the server could indicate non-support of named
attributes by simply reporting that FATTR4_NAMED_ATTR wasn't supported.
Unfortunately, that attribute is listed as mandatory.

I can understand the reasoning for making it mandatory may have been
that even if an implementation doesn't support them it can still always
report "No" for FATTR4_NAMED_ATTR.

My current fallback is to do an OPENATTR(FALSE) on the directory being
mounted and considering a a response of NFS4_OK or NFS4_NOENT as an
indication of support.

But I was wondering if maybe we could consider changing FATTR4_NAMED_ATTR
to be recommended instead of mandatory - and allow servers to indicate
non-support of named attributes by reporting that attribute as not supported.

Thoughts?

Other named attributes questions I have:

What clients support them?

What servers support them?

Do the servers that support them do so for all file system object types?

Is asking for FATTR4_NAMED_ATTR considered expensive?  (enough so that a
client may want to avoid asking for it?)

Mac OS X's VFS interface has an ACCESS API that is as fine-grained
as ACE rights and thus it can query for READ/WRITE access for named
attributes.  The NFSv4 ACCESS operation is not as fine grained as
NFSv4 ACEs so I guess in order to report READ/WRITE_NAMED_ATTRS
access I'm left with calling ACCESS on the named attribute directory
file handle? (and the named attributes in that directory?)

BTW, are there any plans on fixing/extending the NFSv4 ACCESS operation
to allow querying for all the access rights allowed in NFSv4 ACEs?

Thanks
--macko

---

From: Rick Macklem <[email-masked]>
Date: Thu, 3 Sep 2009 19:36:41 -0400 (EDT)

On Thu, 3 Sep 2009, Mike Mackovitch wrote:

[stuff snipped]
> So, how can a client determine if a server supports named attributes?
[more snipped]
> mounted and considering a a response of NFS4_OK or NFS4_NOENT as an
My reading of the "Implementation" para. at the end of Sec. 14.2.7 is
that the server returns NFS4ERR_NOTSUPP for the OPENATTR if it is not
supported.

Now, I don't know of anywhere in the RFC that it states that
this applies to all files and not just the file handle being tested, but
my guess is that it will be supported/not supported across at least a
file system within the server, if not all file systems on the server?

[more stuff snipped]
> What servers support them?
All I can say w.r.t. the rest is that the answer is No for FreeBSD8.
(I have no idea if there will be "subfile" support of any kind in
FreeBSD9.)

rick

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 3 Sep 2009 18:40:22 -0500

> >What servers support them?

Solaris.

> (I have no idea if there will be "subfile" support of any kind in

Well, there is a port of ZFS to FreeBSD...  Wouldn't the FreeBSD
community want to add named attr support just for that reason?

Nico
--

---

From: Mike Mackovitch <[email-masked]>
Date: Thu, 3 Sep 2009 20:36:33 -0700

> that the server returns NFS4ERR_NOTSUPP for the OPENATTR if it is not

Yes.  Well, I've already hit one server that responds to OP_OPENATTR with
opcode OP_ILLEGAL and status NFS4ERR_OP_ILLEGAL.  :-(

Thus, my careful wording above: NFS4_OK or NFS4ERR_NOENT indicates support.
Anything else indicates don't bother trying it.

> file system within the server, if not all file systems on the server?

The RFC specifically doesn't say that it applies to all files, etc.
So, I presume we'll need to handle getting NFS4ERR_NOTSUPP on certain
attempts/object types.  And I was curious if anyone knew of servers
that implemented named attributes on only some object types.

Thanks
--macko

---

From: Rick Macklem <[email-masked]>
Date: Fri, 4 Sep 2009 10:30:29 -0400 (EDT)

>>> What servers support them?
All file object types and all file system types?
(Oh, and is it in Solaris 10 or do you need OpenSolaris?)

Thanks in advance for the answers, rick

---

From: Rick Macklem <[email-masked]>
Date: Fri, 4 Sep 2009 10:28:35 -0400 (EDT)

> community want to add named attr support just for that reason?
I'm hopeful, but I'm just a newbie committer, so I can't speak for
the "collective":-) I suspect the decision will have to do with
how much interest there seems to be within the community for that
feature (and someone with the time to do it, if the community is
interested).

Btw, NFSv4 ACL support did make it in for ZFS, but not UFS/FFS.
(There is a very nice Google SOC project that did NFSv4 ACL support
for UFS/FFS, but there wasn't time to get that merged for FreeBSD8.0.
If it doesn't require any KPI changes, in might make it for 8.n?)

rick

---

From: Rick Macklem <[email-masked]>
Date: Fri, 4 Sep 2009 10:52:12 -0400 (EDT)

> community want to add named attr support just for that reason?
Oops, I have to correct myself here... I just found out that named
attribute support does exist in FreeBSD8. If I had known this sooner,
support might have made it into 8.0. As it stands, it might make it
into 8.n. (If not, I can at least put an experimental patch for it
up somewhere.)

Edward, would you mind clarifying if all file object types have
named attribute support?

rick
ps: Edward is the guy who has been doing all the good NFSv4 ACL
     support, etc, for FreeBSD.

---

From: Robert Thurlow <[email-masked]>
Date: Fri, 04 Sep 2009 08:51:21 -0600

> (Oh, and is it in Solaris 10 or do you need OpenSolaris?)

Support made it into Solaris 10 for most filesystems
and object types, and has changed only slightly since.
NFSv4 clients can see named attributes on shares of ZFS,
UFS and tmpfs filesystems.  We support them on most
filesystem objects, with gaps, e.g. we lack ways to
get the file descriptor of a symlink from user-land,
so there may be no way to put a named attribute on a
symlink.  Our NFSv4 client can access them.  We also
support access on NFSv2/v3 with the sideband NFS_ACL
protocol, and we support SMB named streams on both
client and server with the same mechanism.

Rob T

---

From: Benny Halevy <[email-masked]>
Date: Fri, 04 Sep 2009 23:43:07 +0300

> opcode OP_ILLEGAL and status NFS4ERR_OP_ILLEGAL.  :-(

That's a bug.  The server should have returned NFS4ERR_NOTSUPP
since the operation code is clearly legal in NFSv4.

> Anything else indicates don't bother trying it.

Like Rick said, if the server returned NFS4ERR_NOTSUPP for OPENATTR
it is possible that it supports the operation but named
attributes aren't supported for this particular filehandle
so it might be worth trying on other filesystems exported
by the server.

Again, I agree with Rick that the spec. is clear about
named attribute support for other files in the same filesystem
yet it does make sense to assume that the support for named
attributes is common to all files in the same filesystem
(given by fsid)

Benny

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4