Subject: Openattr issues/clarifications

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 14 Jun 2001 07:07:49 -0700

These are all fairly minor.

First, the DESCRIPTION section for OPENATTR talks 
about using READDIR and LOOKUP to interrogate the 
named attributes, but nothing is mentioned about
how named attributes are created.  OPEN should be 
mentioned in this connection.

Also, under OPEN, it talks about using it to open a
regular file.  Named attributes aren't menioned at 
all.

If the handle returned by OPENATTR is a normal 
persistent handle (e.g. it has the inode number
of a (quasi)-directory inode), there are some
issues that arise from the fact that OPENATRR
will create an empty attribute directory if one 
does not yet exist.  There are other possible
handle formats for this (inode number of the 
base file plus a modifier flag), but that may 
not be convenient for all implementations.

OPENATTR on a read-only file system might fail
if the attribute directory does not exist.
NFS4ERR_ROFS is not in the error list.

Also, if the client does an OPENATTR to interrogate
named attributes, it may have performance and space 
implications.  So the use of the named_attr attribute
to avoid OPENATTR when there is nothing to read
should be encouraged.

The description of the named_attr attribute does 
not make it clear if it is TRUE when there is a named
attrbute directory which is empty.  Making it TRUE
in this case would simplify the implementation of
named_attr (no directory read needed), but would
serve the purpose of named_attr (supposing, that is,
that I understand the purpose).

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 15 Jun 2001 16:14:19 -0500

> mentioned in this connection.

Thanks for pointing this out.  It is on the todo list.

> regular file.  Named attributes aren't menioned at 

Okay.

> not be convenient for all implementations.

This assumes that the server's filesystem implements
the named attribute directory as a "regular" directory
(as you allude to).  There may be implementations that
this is not the case.  The named attribute directory
may be integrated in such a way that it does not
have to be created at OPENATTR.  

> NFS4ERR_ROFS is not in the error list.

That assumes that the server is implementing it this way.
I don't have a strong opinion about which way to go 
with this but we need to decide how much of the 
potential underlying implementation we want to
bubble up into the protocol.

> to avoid OPENATTR when there is nothing to read

Again, this assumes a model that the directory is created at OPENATTR.
If we expose the creation of a named attr directory into the protocl,
then one would assume there would be a way to remove that directory
when it was empty.  Not sure if that is the best thing to do with the
protocol.

In our implementation, we have an underlying filesystem that currently
does what you are suggesting; it creates the attribute directory with
the simple act of doing a lookup of a named attribute within that
directory.  We are attempting to build a solution for the server that
does not activate that named attribute directory until the client
actually OPEN(CREATEs) the named attr.  Sure, we are mucking around
with the filehandles to accomplish this but it seems like we can do it
without too much trouble.

I like the current model because it doesn't assume too much about the
underlying implementation.  Of course, there are tradeoffs.  We can
not directly offer atomicity with writing to a name attribute; the
client would need to build a WRITE/RENAME sequence to accomplish this.

> that I understand the purpose).

The intent is that "named_attr" signifies a non-empty named attribute
directory.  It would be an easy way to avoid an OPENATTR() but if the
server chooses to implement this attribute, it may be non-trivial in
cost depending on the underlying filesystem API/implementation

I will make a note to clarify the description of the named_attr
attribute.

-- 

- Spencer -