Subject: Re: [nfsv4] Named attributes and getxattr

From: Brent Callaghan <[email-masked]>
Date: Thu, 10 Nov 2005 10:35:48 -0800

On Nov 9, 2005, at 5:44 PM, J. Bruce Fields wrote:
> Another alternative would be to keep the two namespaces--extended
> attributes and named attributes--entirely separate.
>
> On Linux that would require an entirely new interface for NFSv4 named
> attributes.  But there seem to be some other people interested in that
> sort of "subfile" model, so that's not out of the question.
>
> There are some odd mismatches between extended attributes and NFSv4
> named attributes; I'm not convinced they're such a good fit.

Yup, xattrs are short strings, atomically set and read.  Subfiles are
infinitely long, read and written incrementally.  Representing
xattrs as subfiles would be an inefficient hack.  I think they need
distinct APIs, namespaces, and protocol support.

My preference would be to have NFSv4 support an attribute that's
an array of xattrs - much as we do now with ACLs.  That would
allow readdir to return them en masse.

BTW: one potential downside of a proliferation of System xattrs is
their potential to agglomerate as a file journeys from one system
to another.  How do we avoid xattr namespace pollution ?

	Brent

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

---

From: David Robinson <[email-masked]>
Date: Thu, 10 Nov 2005 13:24:22 -0600

> distinct APIs, namespaces, and protocol support.

How important is the atomicity? While NFSv4 has almost no atomicity
guarentees, would placing the contents in a READ/WRITE surrounded
by a LOCK/LOCKU (see cur_stateid proposal) be good enough?

A well constructed COMPOUND should allow a get or set with
one round trip, so I don't see much of an efficiency argument.

> allow readdir to return them en masse.

That is an alternative. Is GETATTR/SETATTR atomic enough? Would
it always return all attributes in the list? Or will GETATTR have
a new argument beyond the bitmap to specify return just one?

> to another.  How do we avoid xattr namespace pollution ?

This is a general problem beyond system attributes, as the number
of applications grow that add attributes, and files are copied
or moved between systems, they will agglomerate too. Just look
at the average Unix user's .mumble files in their home directory.
Not sure there is a solution.  For some classes of attributes
the may be primarily read-only, so trying to copy them will fail.
I can imagine an attribute that contains which blocks are filled
versus which blocks are holes. Copying the file will change that
list based on the server implementation, so trying to
write the attribute would fail.

More generally, this is not unlike special device files. Two
different clients may interpret the same file in different
ways. System attributes introduce a third case where the server
may interpret the attribute as well.

My perspective is that the community needs to say something
about xattrs, but not ignore them.  Either they fit within
the existing named attr model, or we create a new
mechanism to deal with them. But I see the getxattr APIs
increasing in deployment (new in MacOS 10.4 I see) so
something needs to be done.

My opinion is that named attrs are under used, while not a
perfect match, its good enough, and could be deployed today
without a new minor version. Can we wait until 4.2?

	-David

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 10 Nov 2005 18:15:52 -0500

> by a LOCK/LOCKU (see cur_stateid proposal) be good enough?

What's the server going to do with that?  I doubt a server that exports
extended attributes as NFSv4 named attributes will want to support
locking on the extended attributes.

--b.

---

From: David Robinson <[email-masked]>
Date: Thu, 10 Nov 2005 18:24:33 -0600

> locking on the extended attributes.

I am really not trying to design a solution, I just want to
get a discussion going on the basics of what the WG's
expectations are. The point was raised that getxattr is
"atomic" for some unknown definition of atomic. I was just
trying to tease out what the degrees of atomicity?

Most servers actually do implement "small" READs and WRITESs
atomically, and it was stated that getxattrs are "small",
so is that good enough? The server knows it is a named attribute
and could just internally make the single READ/WRITE atomic
it it doesn't already.

My point above was, that the next step in making it a harder
atomicity would be to explicitly COMPOUND a LOCK/LOCKU pair,
was that good enough? Yeah its ugly, but that is not the
point.

Even the suggestion of using GETATTR begs the atomicity
question, in the current protocol we don't specify that
all the returned attributes represent a single point in time.
While it is mostly true, I doubt many servers would block
all space allocation to make sure the filesystem wide spaced
used attribute is consistent with the current file size
attribute. If the getxattr interface needs strong atomicity
we would need to clarify/specify this.

The final position is create a whole new OP that by definition
guarentees atomicity.

So how atomic is getxattr? How small is small? Is listxattr atomic
or is it like readdir where things may change between parts of
the list?

Just trying to understand the requirements so we
can evaluate solutions.

	-David

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 15 Nov 2005 15:27:16 -0600

> trying to tease out what the degrees of atomicity?

Good point -- atomicity for a whole xattr is one thing, but I can see
size constraints on xattrs leading to related xattrs such that w/o
atomicity for read-modify-write for all xattrs as a whole then there is
no atomicity.

A question: what applications actually depend on what xattrs being
atomic on what platforms?

> was that good enough? Yeah its ugly, but that is not the

A locking convention seems good enough to me; certainly where locking is
mandatory.

> we would need to clarify/specify this.

True, but then filesystem-wide space availability is a filesystem-wide
attribute, not per-file.  So maybe we need to make that distinction
explicitly.

> Just trying to understand the requirements so we

Examples of apps that depend on xattr atomicity would be nice...

I suspect that xattr atomicity can be tossed out, and that if not then
byte range locking or share reservations should suffice.

As for whether to treat xattrs as subsets of NFSv4 EAs, I don't know,
but not waiting for NFSv4.2 surely must be tempting!  The namespace
issues can be papered over with some conventions, perhaps; w/o some
conventions we'd either need a registry or have to hope that
applications don't collide.

Nico
--