Subject: Re: ReadDir and file attrs

From: "Sergey Klyushin" <[email-masked]>
Date: Thu, 14 Oct 1999 17:02:50 -0400

>>
>> There could be a problem if NFS Server can't fill all requested file
>> attributes.
>>
>> Protocol says that NFS Server should return error if it supports
>> attribute, but can't get its value (for GETATTR).  What NFS Server
>> should do in READDIR case?  Don't return file_name at all? - BAD Return
>> error? - BAD.  NFS v.3 allows don't return any post_attributes in this
>
>I agree that skipping the directory entry is unacceptable,
>
>It seems to me the likelyhood of GETATTR returning error for a
>supported attribute is low, so I don't think it is bad to return an
>error for the entire READDIR.

If Server returns error for READDIR, it can't return dir. entries at the
same time, so Client has to start READDIR from the beginning (or
at least from the last cookie). RPCs overhead?
BTW what error Server should return now in that case? The error is related
to
the file, but not to the directory.

>Perhaps I'm being myopic; are
>there examples of attributes that periodically return errors?

ACL, owner, group,.... if ACL database is locked locally by the OS
(could be others)

>
>> case (READDIRPLUS), but with NFS v.4 Server should return error for
>> READDIR.  My suggestion is don't return error, but return as much
>> attributes as possible and for missing attributes NFS Client can use
>> GETATTR later.  It means, that bitmap_mask will have different meaning
>> for GETATTR and READDIR.  1 - means that attribute is present in
>> attrlist_val, and 0 - means that attribute can't be retrieved this
>> time, but not that it's not supported. NFS Client can always ask what
>> attributes are supported with GETATTR request and supp_attr bit set.
>> Probably the same meaning of bits in bitmap's "attrmask" is useful for
>> GETATTR also.
>
>This takes us down the slippery slope of optional post-op attributes
>which made NFS V3 client's complex. With the current attribute design,
>if the client asks for an attribute, and doesn't get it, then he knows
>he has to fake it for the application. Once you go to optional
>post-op attributes, the client has to make additional RPCs to determine
>what the situation is.
>

There is no way to return an error AND file list at the same time. I guess
that
it will be much more additional RPCs if Server returns error and NO file
list,
than returns OK (or some error) AND file list plus all available now
attributes.
It could be the case that Server failed to get only one attribute for only
one file. Client has to send only one RPC (GETATTR) for that file in this
case,
but not to start all READDIR from the beginning.

>If we think that GETATTR failures are going to be common, then
>we should re-visit the issue for GETATTR as well as READDIR.
>
> -mre
>
>

---

From: Mike Eisler <[email-masked]>
Date: Thu, 14 Oct 1999 14:49:25 -0700 (PDT)

> the file, but not to the directory.

Yes. As long as this is infrequent, this doesn't strike me as a big issue.

> ACL, owner, group,.... if ACL database is locked locally by the OS

Could you provide more details? It seems to me that if an ACL can be locked
for an indefinite period of time, them maybe one shouldn't request the ACL on
the READDIR, or in tandem with any other attribute in a GETATTR. Given the
idefinite length of an ACL, asking for it in the READDIR operation seems like
trouble.

> but not to start all READDIR from the beginning.

There is a way if we change what an fattr4 or an entry4
looks like. But I don't like the notion of fattr4's semantics being
different when used in the context of GETATTR results versus
READDIR results.

	-mre