Subject: [nfsv4] Named attributes

From: "Sergey Klyushin" <[email-masked]>
Date: Thu, 30 Oct 2003 17:25:58 -0500

Hello,

Could you help me with the following questions about named attributes?

1) 5.  File Attributes
   Therefore, operations such as SETATTR and GETATTR on the
   named attribute directory are undefined.

What does it mean? Should NFS Server always return error on SETATTR and 
GETATTR for fh returned from OPENATTR? If yes, what error? NFS4ERR_NOTSUPP?
Where and how Server may return NF4ATTRDIR object type if GETATTR undefined
on named attribute directory?

2) 5.3.  Named Attributes
   Named attributes may have attributes.

Does it mean that Server MUST support at least all mandatory attributes for 
named attributes?

3) 5.5.  Mandatory Attributes - Definitions
   ___________________________________________________________________
   supp_attr         0    bitmap       READ     The bit vector which
                                                would retrieve all
                                                mandatory and
                                                recommended attributes
                                                that are supported for
                                                this object.  The
                                                scope of this
                                                attribute applies to
                                                all objects with a
                                                matching fsid.

Looks like fsid for named attributes MUST be different from fsid of 
original file where OPENATTR was issued or named attributes and original 
file MUST have at least the same set of attributes. Is it correct?

4) 5.3.  Named Attributes
   Named attributes
   may then be examined or changed by normal READ and WRITE and CREATE
   operations on the filehandles returned from READDIR and LOOKUP.

May CREATE be used on fh returned from LOOKUP?
May CREATE be used on fh returned from OPENATTR?

How CREATE (for example symlink) will work for named attributes?
Is the following legal?
OPENATTR (fh1)
  <-- fh2
CREATE (fh2, NF4LNK, linktext4, new_named_attribute_name, createattrs)
What if Server doesn't support symlink (or NF4DIR, NF4SOCK, ...) for named 
attributes? 
What if Server doesn't support attributes for named attributes? 
What error to return? There is no ERR_NOTSUPP

4.1) BTW, what should be done for regular CREATE if Server doesn't support
some of nfs_ftype4? There is no ERR_NOTSUPP

5) Is the following legal?
OPENATTR (fh1)
  <-- fh2
OPEN (create, fh2)
  <--- fh3, open_stateid
LOCK (fh3, open_stateid)
  <--- lock_stateid
WRITE (fh3, lock_stateid)
UNLOCK (fh3, lock_stateid)
CLOSE (fh3, open_stateid)
MUST NOT be any CLOSE for fh1 and fh2

Thanks in advance,
Sergey 

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

---

From: "Khan, Saadia" <[email-masked]>
Date: Fri, 31 Oct 2003 16:53:34 -0800

> -----Original Message-----
> From: Sergey Klyushin [mailto:[email-masked]] 
> Sent: Friday, October 31, 2003 4:28 PM
> To: Khan, Saadia; [email-masked]
> Subject: RE: [nfsv4] Named attributes
> 
> 
> > >
> > What do you mean by the last line?
> > 
> 
> 1. By the last line I mean that client must not send CLOSE 
> corresponding to OPENATTR.

How can the client send a close for the openattr. Openattr does not
create any state on the server and hence does not give out a stateid
which is required by a close.

> 2. By the rest I mean that named attributes may be used as 
> regular files: Client may open, create (USING OPEN ONLY, BUT 
> NOT USING CREATE), lock, 
> Read, write, setattr, getattr, rename,... named attributes.
> 

Yes, a client can do *almost* everything on a named attribute that it
can do on a regular file, again based on the server implementation.

> Thanks,