Subject: RE: [nfsv4] Named attributes

From: "Khan, Saadia" <[email-masked]>
Date: Fri, 31 Oct 2003 11:56:46 -0800

> -----Original Message-----
> From: Sergey Klyushin [mailto:[email-masked]] 
> Sent: Thursday, October 30, 2003 2:26 PM
> To: [email-masked]
> Subject: [nfsv4] Named attributes
> 
> 
> 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?

Currently we return EPERM for a setattr on a named attribute dir. For
getattrs we return whatever are the attributes on the named attr dir
which are the same as the base file except the size.

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

Yes, except for size, all other attributes should be the same for both.

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

I think this is upto the server if it allows creating non-regular file
objects in the named attr dir.

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

Use EINVAL? Maybe we should add this error to create.

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

What do you mean by the last line?

> 
> 
> Thanks in advance,
> Sergey 
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: Jeff Smith <[email-masked]>
Date: Fri, 31 Oct 2003 16:27:38 -0600

> which are the same as the base file except the size.

The Solaris UFS implements named attrs such that the attrdir is
constructed exactly like any other dir *except* that the directory
is not in the file system's namespace -- it is associated with the
base file another way.  So, our attrdir can have different attrs than
the base file.  I think the spec language just allows wiggle room for
implementation of an attrdir as a "real" fs object with distinct
attrs or a synthetic object which returns attrs from the base object.

>>Does it mean that Server MUST support at least all mandatory 

I agree with the generic statement that a server MUST support all
mandatory attrs (without regard to the type of the object).
However, I don't think this is what section 5.3 above was intended
to convey.  I think it means that an implementation could be twisted
enough to have nested named attrs (ie. file foo has a named attr
call bar, and the bar attribute has one or more named attrs).

Our implementation isn't that twisted...  :-)

> Yes, except for size, all other attributes should be the same for both.

I think you're asking what is returned for the supp_attr attribute
on the original file and a named attr of that file.  Our server returns the
same supp_attr bitmap for an object, an object's attr dir, and an object's
named attr.  The fsid is also the same for each.

> objects in the named attr dir.

I agree with Saadia.  Mentioning CREATE here just covers implementations
that permit creation of hardlinks/symlinks/special files/whatever within
the attr dir.  Solaris UFS allows hardlinks to be created to other
attrs within the attrdir.

> Use EINVAL? Maybe we should add this error to create.
The solaris server just maps the error returned by the
underlying fs to a protocol error.  Currently Solaris
UFS returns EINVAL for creation of symlinks in attr dirs
(or creation of dirs, spec files, etc.).

---

From: "Sergey Klyushin" <[email-masked]>
Date: Fri, 31 Oct 2003 19:27:32 -0500

> What do you mean by the last line?

1. By the last line I mean that client must not send CLOSE 
corresponding to OPENATTR.
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.

Thanks,
Sergey