Subject: RE: Issues list for RFC3010

From: "Khan, Saadia" <[email-masked]>
Date: Thu, 20 Sep 2001 10:35:16 -0700

-----Original Message-----
From: Khan, Saadia 
Sent: Wednesday, September 19, 2001 6:29 PM
To: [email-masked]'; [email-masked]
Cc: Khan, Saadia
Subject: RE: Issues list for RFC3010

I would like to add some more things to the list which are not very clear as far as the spec goes:

Named Attributes:

1. Does it make sense to allow setattr on a named attribute dir? Is that allowed in the spec? And if so what does it mean if the named attr dir has different perms, uid, gid from the base file and in that case which one is used for permission checking?

In similar context, does it make sense to do the same for named attributes? Or does changing perms, uid, gid for a named attribute change the perms, uid, gid for the base file.

2. Currently a server is required to first check if a named attribute dir
associated with a file/dir actually contains any named attributes before 
returning TRUE in the named_attr field for getattr. 

There can be a couple of issues with that. First its very improbable to have a named attr dir without any named attrs, and second it is possible that a client is requesting the server for all supported attributes every time it does a stat call. It can be very expensive for the server to check if the directory is empty or not everytime it gets one of these calls.

It should be sufficient for the server to check if the dir exists and return TRUE  for named_attr.

3.Should exclusive create be supported for named attributes?

4. Does it make sense to rename a named attribute? I dont think it makes sense to rename a named attribute between different base files. Within the same file, maybe but even that doesn't make much sense. 

5. Does the spec support deleting the named attribute dir? I think that deleting a file with named attributes should delete everything with it, including the dir and all named attributes or the client should be allowed to delete a single attr.
But allowing a named attr dir to be deleted without deleting the base file doesn't really make much sense.

thanks,
Saadia

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]]
Sent: Wednesday, September 19, 2001 5:48 PM
To: [email-masked]
Subject: Issues list for RFC3010

I have an updated issues list at:

http://www.nfsv4.org/rfc3010updates/issues.html

Updates will follow.

-- 

- Spencer -

---

From: "Jeff A. Smith" <[email-masked]>
Date: Thu, 20 Sep 2001 23:01:52 -0500

"Khan, Saadia" wrote:
> 1. Does it make sense to allow setattr on a named attribute dir? Is that
> allowed in the spec? And if so what does it mean if the named attr dir has 
> different perms, uid, gid from the base file and in that case which one is 
> used for permission checking?
> 
> In similar context, does it make sense to do the same for named attributes? 
> Or does changing perms, uid, gid for a named attribute change the perms, uid, 
> gid for the base file.
> 

        As I understand it, the spec provides a way to get a filehandle for the 
        attribute directory with OPENATTR, but it does not restrict the how that 
        filehandle can be used.  The underlying server fs may restrict the set of 
        operations allowed on attrdirs (for reasons you mentioned), but the spec 
        does not.  I think this general answer addresses most of your questions.

> There can be a couple of issues with that. First its very improbable to have 
> a named attr dir without any named attrs, and second it is possible that a 
> client is requesting the server for all supported attributes every time it 
> does a stat call. It can be very expensive for the server to check if the 
> directory is empty or not everytime it gets one of these calls.
> 
	In this case, the spec is trying to be general enough to provide useful
	information to applications without assuming a particular server fs 
	implementation.  I know of at least one server fs where empty attr dirs 
	are not rare.  The attrdirs in this file system are like regular dirs 
	in that they are not removed when the last named attribute is removed.  
	I'm not saying I think that design is correct or that I like it -- I'm 
	just saying it exists.  

	If you believe that it is reasonable for an app to set several 
	attributes and clear them later, then empty attr dirs may not be such
	a rare occurrance in the server file system.  For such a file system, 
	checking to see that the attrdir exists would not provide very useful 
	info to the app -- especially if all file system objects had a named 
	attribute at some point in their lifetime.

	I'm not sure I agree with your first statement that servers
	must check to see that the attrdir actually contains attributes
	before returning TRUE for named_attr.  The server must answer
	the question correctly, but it might not have to do readdir
	to do so.  If you're writing a nfsv4 server, and all server filesystems 
	remove attrdirs after the last attribute is deleted, (and 3rd party
	filesystems are not possible), then you can certainly code your 
	NFSv4 server to take advantage of that and simply check for the 
	existance of the attr dir instead of doing readdir. 

> 3.Should exclusive create be supported for named attributes?

	I don't see any reason why it shouldn't, and the spec doesn't specifically
	disallow it, so I would say yes.  I don't have a strong argument for either
	position, and I generally dislike arbitrary restrictions...  This sounds like 
	a good thing to be explicitly stated in the spec.

> 4. Does it make sense to rename a named attribute? I dont think it makes
>    sense to rename a named attribute between different base files. Within 
>    the same file, maybe but even that doesn't make much sense.
> 
	Again I don't really have a position, and the spec is general enough
	to support implementations that support renaming attributes as well
	as those that don't.  Perhaps named attrs should be mentioned in the
	"rename" implementation section of the spec.

	I don't have any experience coding apps that use named attrs, so my
	$0.02 is more like $0.005, but one use of renaming attributes would be
	to enable atomic set (create named attr with a temp name, write all
	attr data, then rename it to whatever the "real/proper" name).
		
> 5. Does the spec support deleting the named attribute dir? I think that 
> deleting a file with named attributes should delete everything with it, 
> including the dir and all named attributes or the client should be allowed 
> to delete a single attr.
	Because the attrdir has no name and the spec doesn't define a
	RM_ATTR_DIR op, there's no way to explicitly delete the attrdir.
	The only way I know of to delete the attrdir is to implicitly 
	delete it by the deleting the base file.  This is also a good 
	candidate for clarification in the spec.  

	Of course, a server fs implementation would be free to delete the 
	attrdir after the last attribute was removed.  So, it could be 
	possible for the attrdir to be removed without removing the 
	"base file" -- it depends on the server fs implementation.  I
	think it would be totally broken to be able to remove a file 
	without	also removing its attributes.

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 21 Sep 2001 02:57:04 -0500

>         does not.  I think this general answer addresses most of your questions.

As Jeff mentions, the named attribute support was intentially under
specified.  I believe the things you ask about could be allowed for
certain implementations but I doubt they would not be very useful.  My
preference is to leave this type of functionality under specified and
allow client named attribute APIs and server implementations drive
further definition while not restriction the protocol to a particular
implementation.

I will add an item to the issues list to discuss the possible
implementations and pitfalls of such.

> 	existance of the attr dir instead of doing readdir. 

I don't expect that clients will ask about named attributes that much
in the general case.  We could add language that discourages the
overuse of the named_attr attribute if that would help.

> 	a good thing to be explicitly stated in the spec.

Since we have taken the model that general operations apply named
attributes, the answer would be yes.  However, with the case of
exclusive create, we need to be sure that this is something that is
applicable in the implementations that are planned.  Would like to
avoid specifying something that will not be implemented and removed
from the specification later on. :-)

> 	attr data, then rename it to whatever the "real/proper" name).

Right. This is the example that I have always thought of.  Since there
are named attribute APIs that require atomicity with respect to
setting a value of the named attribute and NFSv4 does not provide that
type of atomicity, a WRITE/RENAME sequence could be used in its place.

For the case of rename of a named attribute between filesystem
objects, I believe that is unlikely and the server can return
NFS4ERR_XDEV in this case (and probably should).  I will add this
clarification to the RENAME operation IMPLEMENTATION section.

> 	without	also removing its attributes.

Jeff, did you mean to say something like, when a file is REMOVEd the
named attributes associated with that file should automatically be
removed (implicitly).  It isn't the responsibility of the client to
first remove all of the named attributes before removing the
filesystem object.  This is different from removal of a regular
directory that is non-empty.  

The key in the NFSv4 named attribute support is that it allows for
various implmentations.  It is possible that the attribute directory
returned from OPENATTR doesn't have a corresponding directory at the
server.  The server may choose to implement named attributes in a way
that really doesn't have a physical directory in the server
filesystem.

The specification also allows for named attributes of named
attributes.

I realized via this discussion that I had missed an issue related to
named attributes.  We had discussed on the WG alias the addition of a
CREATE flag to OPENATTR to provide for server implementations that do
not create a named attribute directory until the first named attribute
is actually created.  Therefore, if the client is just reading the
attribute directory without the intent of creating a named attribute
it can used OPENATTR() and the server can return NFS4ERR_NOENT.  If
the client is going to create a named attribute, then it can use
OPENATTR(CREATE) to have the named directory activated.

I will add this to the issues list.

- Spencer -