5:10 p.m.
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
6:28 a.m.
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(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
6:45 a.m.
Great to know. Thanks for the quick reply.
On Tue, Sep 29, 2020 at 9:30 PM Daniel Gryniewicz <dang(a)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(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
7:19 a.m.
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(a)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(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
8:13 a.m.
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(a)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(a)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(a)lists.nfs-ganesha.org
> > To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
> >
> _______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>
11:39 a.m.
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(a)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(a)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(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
> To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
11:42 a.m.
I'm not sure. I'm not the expert on Proxy. It might, if that's the
cause of the failure (and the 24 hours seems suspicious). I would
expect the cached creds to be refreshed transparently to ganesha's
clients, but there may be a bug there.
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(a)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(a)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(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
> To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
To unsubscribe send an email to
devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
12:11 p.m.
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(a)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(a)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(a)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(a)lists.nfs-ganesha.org
> > <mailto:devel@lists.nfs-ganesha.org > >
> To unsubscribe send an email to
> > devel-leave(a)lists.nfs-ganesha.org
> > <mailto:devel-leave@lists.nfs-ganesha.org > > > >
_______________________________________________
> > Devel mailing list -- devel(a)lists.nfs-ganesha.org
> > <mailto:devel@lists.nfs-ganesha.org > >
To unsubscribe send an email to
> > devel-leave(a)lists.nfs-ganesha.org
> > <mailto:devel-leave@lists.nfs-ganesha.org > >
_______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
7:34 a.m.
Okay, so I had missed something. Sounds like Frank has a handle on it?
Daniel
On 9/29/20 1:11 PM, Olivier Garaud wrote:
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(a)redhat.com
<mailto: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(a)scality.com <mailto:olivier.garaud@scality.com>
<mailto: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(a)redhat.com <mailto:dang@redhat.com>
> <mailto: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(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
> <mailto:devel@lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>>
> > To unsubscribe send an email to
> devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
> <mailto:devel-leave@lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>>
> >
> _______________________________________________
> Devel mailing list -- devel(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
> <mailto:devel@lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>>
> To unsubscribe send an email to
> devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
> <mailto:devel-leave@lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>>
>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
<mailto:devel@lists.nfs-ganesha.org>
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
<mailto:devel-leave@lists.nfs-ganesha.org>
1310
days inactive
1312
days old
8 comments
3 participants
participants (3)
-
Bjorn Leffler -
Daniel Gryniewicz -
Olivier Garaud