Thanks for your answer Daniel,

I'm talking about this case in https://tools.ietf.org/html/rfc7530#page-271

In some cases, the server may encounter an error while obtaining the

attributes for a directory entry. Instead of returning an error for

the entire READDIR operation, the server can instead return the

attribute 'fattr4_rdattr_error'. With this, the server is able to

communicate the failure to the client and not fail the entire

operation in the instance of what might be a transient failure.

Obviously, the client must request the fattr4_rdattr_error attribute
for this method to work properly. If the client does not request the

attribute, the server has no choice but to return failure for

the entire READDIR operation.

What I've seen on my system is a full directory listing failing because I cannot stat one of the entries.

I do believe that some handling of fattr4_rdattr_error is missing in mdcache_readdir_chunked

We have this comment:

/* Ensure the attribute cache is valid. The simplest way to do
* this is to call getattrs(). We need a copy anyway, to ensure
* thread safety.
*/

But I've no idea of the consequences of not filling the cache here for the failing entries

Does that make more sense ?

Olivier

On Tue, Sep 29, 2020 at 6:40 PM Daniel Gryniewicz <dang@redhat.com> wrote:

I'm not sure understand correctly, but if I do, then I think I disagree.
We need to have valid attributes for all the objects in the readdir,
so if we can't get them for one object, the readdir must fail.

Daniel

On 9/29/20 9:13 AM, Olivier Garaud wrote:
> I'm sorry the issue is a little bit more tricky, I'll try to explain it
> clearly:
>
> When we do a READDIR (mdcache_readdir_chunked) we always refresh the
> attribute cache, which may fail temporarily for one entry and at that
> point the fattr4_rdattr_error is not handled correctly.
> Which may fail the whole READDIR and that's not what should happen in
> that case.
>
> Olivier
>
> On Tue, Sep 29, 2020 at 2:19 PM Olivier Garaud
> <olivier.garaud@scality.com <mailto:olivier.garaud@scality.com>> wrote:
>
> Hi,
>
> I think we may have an issue with this since the fattr4_rdattr_error
> attribute is not transferred to the FSAL.
> See https://tools.ietf.org/html/rfc7530#page-271
>
> Regards,
>
> Olivier
>
> On Tue, Sep 29, 2020 at 1:30 PM Daniel Gryniewicz <dang@redhat.com
> <mailto:dang@redhat.com>> wrote:
>
> It doesn't. The readdir() API requires that the callback be
> called with
> the requested attributes, so it's up to the FSAL to make sure
> they're
> there, by calling the appropriate getattr() call if necessary.
>
> Daniel
>
> On 9/28/20 6:10 PM, Bjorn Leffler via Devel wrote:
> > How does Ganesha (especially MDCACHE) handle readdir
> responses when some
> > or all files have no attributes? Is this supported and
> supposed to work?
> >
> > I'm testing proxy configurations against a NetApp filer.
> NetApp filers
> > don't return attributes in the readdir response for .snapshot
> directories.
> >
> > Thanks,
> > Bjorn
> >
> >
> > _______________________________________________
> > Devel mailing list -- devel@lists.nfs-ganesha.org
> <mailto:devel@lists.nfs-ganesha.org>
> > To unsubscribe send an email to
> devel-leave@lists.nfs-ganesha.org
> <mailto:devel-leave@lists.nfs-ganesha.org>
> >
> _______________________________________________
> Devel mailing list -- devel@lists.nfs-ganesha.org
> <mailto:devel@lists.nfs-ganesha.org>
> To unsubscribe send an email to
> devel-leave@lists.nfs-ganesha.org
> <mailto:devel-leave@lists.nfs-ganesha.org>
>
_______________________________________________
Devel mailing list -- devel@lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org