David, Sorry, the list got removed from the CC at some point… We do have a developer community call on Tuesdays at 7:00 AM Pacific Time (not sure what timezone you’re in). We use Google Meet. Ganesha community call Tuesday, June 14 · 7:00 – 7:30am Google Meet joining info Video call link: https://meet.google.com/mkh-ctnj-tqz Or dial: ‪(US) +1 401-702-0462 PIN: ‪495 972 631# More phone numbers: https://tel.meet/mkh-ctnj-tqz?pin=2844708468265 Or join via SIP: sip:2844708468265@gmeet.redhat.com We also have an IRC channel (#ganesha) on Libera.chat. I can also do Zoom or Google Meet if you want to chat individually. What is the backend you are trying to implement on? You have mentioned VFS and kernel attr cache. Linux or some other OS? Frank From: David Rieber [mailto:drieber@google.com] Sent: Monday, June 13, 2022 4:32 PM To: Frank Filz <ffilzlnx@mindspring.com> Subject: Re: [NFS-Ganesha-Devel] Re: How FSAL readdir should report rdattr_error ? Thank you Frank. Please know I am very very very new to ganesha and NFS :-) What you are saying roughly matches what I think I saw when going through ganesha codebase. In particular, like you said, there is no field in struct attrlist to store the rdattr_err! It may turn out that I don't need this feature so much after all. There is a story behind why I thought we may need this: it has to do with an observation that the kernel attr cache appeared to not be working. It is a long story. Would it be possible to arrange a zoom call to ask questions in that format? I understand if you prefer to stick to email. Also, AFAICT you are replying to me directly rather than to the mailing list: https://lists.nfs-ganesha.org/archives/list/devel@lists.nfs-ganesha.org/thre... .... Am I confused? Why not post to that thread? This is not a huge deal, I was just curious :-) Thanks! On Mon, Jun 13, 2022 at 12:15 PM Frank Filz <ffilzlnx@mindspring.com <mailto:ffilzlnx@mindspring.com> > wrote: David, OK, I’ve looked through the code some. While I coded some of that RDATTR_ERR stuff originally, I really can’t make sense of it anymore… If you feel like you might actually fail to get attributes, then you might want to set up a test that actually does so, and figure out what happens… We do have support for NFSv4 junction crossing failing, but that’s handled up in the protocol layer not the FSAL layer. One consideration is that in order to resolve a file handle to an object (or produce a file handle from LOOKUP or CREATE) we need the base attributes to know what type of object it is. And I do know that currently we don’t support partial sets of base (POSIX) attributes. There doesn’t seem to be a mechanism to pass the actual error for RDATTR_ERR up from the FSAL (at the protocol layer we can produce NFS4ERR_MOVED or NFS4ERR_WRONGSEC). So if you really do need to pass up RDATTR_ERR, we probably need some work to have fsal_status_t rdattr_err in struct attrlist so the error can be passed up. And then we need to figure where in GETATTR and READDIR we should handle the errors. Frank From: David Rieber [mailto:drieber@google.com <mailto:drieber@google.com> ] Sent: Monday, June 13, 2022 9:37 AM To: Frank Filz <ffilzlnx@mindspring.com <mailto:ffilzlnx@mindspring.com> > Subject: Re: [NFS-Ganesha-Devel] Re: How FSAL readdir should report rdattr_error ? I do not have a specific scenario right now, but since I am working on a VFS I have to be prepared to properly implement the readdir API, and in particular the fsal_readdir_cb. The way I understand it, readdir takes a attrmask representing the requested attributes. My FSAL must invoke the fsal_readdir_cb once for every directory entry. If for whatever reason the FSAL cannot produce all the requested attributes, the NFSv4 protocol specifies that attribute "rdattr_error" (attribute 11) should be used. My question is how to implement this. In ganesha fsals I see other functions that do stuff with RDATTR_ERR, for example proxyv4_getattrs has this snippet: ... if (rc != NFS4_OK) { if (attrs->request_mask & ATTR_RDATTR_ERR) { /* Caller asked for error to be visible. */ attrs->valid_mask = ATTR_RDATTR_ERR; } return nfsstat4_to_fsal(rc); } ... Strangely I don't see anything similar for readdir. My guess is readdir should do this to signal a "read attribute error": attrs->valid_mask = ATTR_RDATTR_ERR; Can you confirm? p.s. I am new to this mailing list, so I may be missing something but..... I don't see your reply to my message on https://lists.nfs-ganesha.org/archives/list/devel@lists.nfs-ganesha.org/thre... .... Can you re-post your June 10 reply there so it is easily available to the whole community? Thanks! On Fri, Jun 10, 2022 at 4:39 PM Frank Filz <ffilzlnx@mindspring.com <mailto:ffilzlnx@mindspring.com> > wrote: David, Sorry, I meant to respond to this and got distracted. I will try and respond next week. What attributes are you not able to provide? Frank

-----Original Message----- From: David Rieber via Devel [mailto:devel@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> ] Sent: Friday, June 10, 2022 1:49 PM To: devel@lists.nfs-ganesha.org <mailto:devel@lists.nfs-ganesha.org> Subject: [NFS-Ganesha-Devel] Re: How FSAL readdir should report rdattr_error ?

The wording of my question may be unclear. Essentially what I am asking is how the READDIR callback should behave when the FSAL cannot get all the requested attributes. _______________________________________________ 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>