Subject: RE: Openattr issues/clarifications

From: "Noveck, Dave" <[email-masked]>
Date: Sun, 17 Jun 2001 05:59:20 -0700

Spencer Shepler wrote:
> On Thu, Noveck, Dave wrote:
> > 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.
>
> Thanks for pointing this out.  It is on the todo list. 
> >
> > Also, under OPEN, it talks about using it to open a
> > regular file.  Named attributes aren't menioned at 
> > all.
> 
> Okay.

> > 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.
> 
> 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.  

I'm not saying this is the only implementation, but
rather that it is one possible implementation.  Clearly
there are others that don't have these issues.  The
question is whether the protocol, without any major 
change can accommodate this naive implementation.
  
> > OPENATTR on a read-only file system might fail
> > if the attribute directory does not exist.
> > 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.

If the implementation that I discussed above is a
possible implementation (not excluding others) then
it should be allowed to return NFS4ERR_ROFS in this
situation.  I'm not saying an implementation has to.

The issue here is that OPENATTR is implicitly 
OPEN-and-create-if-it-doesn't-exist-ATTR, but the
issues that that gives rise to can be finessed if you are
willing to play certain games with handles. (e.g.
make the handle returned by OPENATTR the same as that
for the underlying except for a flag so that no real
obect is ever created as a result of OPENATTR).  So
the question is whether such tricks are required by
the protocol or whether you have a choice to do them 
or not.

> > 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.
> 
> 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.

The fact that OPENATTR hay have performance and space implications
(if it is a fact), does not assume the implementation in which a 
directory is physically created if it doesn't exist.  It does assume
that it is a possible implementation, though.

As far as the protocol does, you have an operation OPENATTR that
returns a filehandle to a directory-like object.  From the outside,
that sure seems like an operation that creates something if it doesn't
exist, even though as you point out, this doesn't have to be the
implementation.

As far as delete operation, I don't see a pressing need for it if
the only cases of empty name attribute directories are those had
named attributes and had them removed.  The situation is different
if someone looking named attributes creates these directories.
I don't see that adding a delete operation is a big deal either.
The implementation you're thinking of would treat it as a no-op.

> 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.

In my implentation, it's at least an annoyance.  I'm sure it can be
gotten around but it is work I'd rather spend on other things.

> 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.

I think it assumes a lot about the underlying implementation without
appearing to on the surface.  Basically, you have to return some "funny"
handles that are handles to a directory but don't directly designate 
that directory.  As the spec stands, nothing else is really going to 
work, but the spec doesn't tell you any of that.

I think the simplest way of accommodating multiple styles of
implementation of this feature is to add a boolean parameter to
OPENATTR.  If FALSE, OPENATTR would fail if there were no
named attributes associated with the file.  This would be
open for interrogate.  If TRUE, it would not fail if there
were not attributes (or no such directroy although that is
not something that is explicitly visible in the protocol).
That would open to modify and it would fail on a read-only
fs.  Creation per se of the named attribute directory would
not be called out as a protocol-visible event but it would
allow an implementation to avoid superfluous creations when
only interrogations are required. 

> > 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).
> 
> 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.

---

From: Spencer Shepler <[email-masked]>
Date: Mon, 18 Jun 2001 09:09:17 -0500

> only interrogations are required. 

This seems like a reasonable protocol modification.

Anyone else have an opinion?

Spencer

---

From: Robert Thurlow <[email-masked]>
Date: Mon, 18 Jun 2001 10:06:27 -0600 (MDT)

> Anyone else have an opinion?

Strong thumbs-up from me, coupled with apologies for not proposing
this earlier.  We ran into these exact issues with NFS V2/V3 for
an implementation of extended attributes for Solaris.  We extended
the NFS_ACL protocol to provide over-the-wire support, and indeed
found the flag darned handy.

Rob T