On 08/07/2018 01:03 PM, ntvietvn(a)gmail.com wrote: > Hello, > > Can anyone explain how O_TRUNC is handled (open2)? When I try to open an > existing file with this flag, the FSAL_O_TRUNC in openflags is not enabled > in my FSAL open2 fct. > While capturing with tcpdump, the NFS client actually sends a OPEN then > SETATTR with size = 0 but not ctime. > > By looking at an example in open_by_handle, if IIUC if the flag O_TRUNC > is there, we refresh the attrs by calling getattrs to attrs_out, I do not > understand that, why it does that instead of calling setattrs ? > > It should work (and, in fact, passes tests, so it does...) Here's what happens: In nfs4_op_open() It checks the attributes to set for ATTR_SIZE, and if that's zero, it sets FSAL_O_TRUNC in openflags. This is passed to: fsal_open2(), which does the same check, and again sets FSAL_O_TRUNC in openflags. If there's no name (this is an open-by-handle), openflags is passed to obj_ops->open2(); if there's a name, it's passed to open2_by_name(), which passes it to obj_ops->open(). Either way, it gets to: mdcache_open2() which calls mdc_open2_by_name() (if there's a name) which calls obj_ops->open2(), or directly calls obj_ops->open2(); in either case, that's calling into the FSAL with FSAL_O_TRUNC set. Once that returns, if that flag is set, MDCACHE invalidates the cached attributes for that handle. So, it looks like it should be working properly. Daniel _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org

Thanks Daniel, I've just tested it again and confirm that it works, sorry for the noise. But why in GPFS for example we getattrs in case of truncated instead of setting attrs with size and new ctime? (open_by_handle) Thank you On Tue, Aug 7, 2018 at 7:22 PM, Daniel Gryniewicz <dang(a)redhat.com <mailto:dang@redhat.com>> wrote: On 08/07/2018 01:03 PM, ntvietvn(a)gmail.com <mailto:ntvietvn@gmail.com> wrote: Hello, Can anyone explain how O_TRUNC is handled (open2)? When I try to open an existing file with this flag, the FSAL_O_TRUNC in openflags is not enabled in my FSAL open2 fct. While capturing with tcpdump, the NFS client actually sends a OPEN then SETATTR with size = 0 but not ctime. By looking at an example in open_by_handle, if IIUC if the flag O_TRUNC is there, we refresh the attrs by calling getattrs to attrs_out, I do not understand that, why it does that instead of calling setattrs ? It should work (and, in fact, passes tests, so it does...)  Here's what happens: In nfs4_op_open() It checks the attributes to set for ATTR_SIZE, and if that's zero, it sets FSAL_O_TRUNC in openflags.  This is passed to: fsal_open2(), which does the same check, and again sets FSAL_O_TRUNC in openflags.  If there's no name (this is an open-by-handle), openflags is passed to obj_ops->open2(); if there's a name, it's passed to open2_by_name(), which passes it to obj_ops->open(). Either way, it gets to: mdcache_open2() which calls mdc_open2_by_name() (if there's a name) which calls obj_ops->open2(), or directly calls obj_ops->open2(); in either case, that's calling into the FSAL with FSAL_O_TRUNC set. Once that returns, if that flag is set, MDCACHE invalidates the cached attributes for that handle. So, it looks like it should be working properly. Daniel _______________________________________________ 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>

> The open2() API returns the updated attributes of the file. So, if they changed > (for example because of a truncate) then we need a getattrs() to return the new > attributes. The actual truncation is taken care of by the actual open call > (GPFSFSAL_open() -> fsal_internal_handle2fd() -> > OPENHANDLE_OPEN_BY_HANDLE) > > If a FSAL had an extended open call that returned attributes directly, then it > wouldn't need a separate getattrs(). It looks like MDCACHE invalidates the attributes on open2 by handle with truncate though... Frank > Daniel > > On 08/07/2018 01:36 PM, Tuan Viet Nguyen wrote: > > Thanks Daniel, > > > > I've just tested it again and confirm that it works, sorry for the > > noise. But why in GPFS for example we getattrs in case of truncated > > instead of setting attrs with size and new ctime? (open_by_handle) > > > > Thank you > > > > On Tue, Aug 7, 2018 at 7:22 PM, Daniel Gryniewicz <dang(a)redhat.com > > <mailto:dang@redhat.com>> wrote: > > > > On 08/07/2018 01:03 PM, ntvietvn(a)gmail.com > > <mailto:ntvietvn@gmail.com> wrote: > > > > Hello, > > > > Can anyone explain how O_TRUNC is handled (open2)? When I try to > > open an existing file with this flag, the FSAL_O_TRUNC in > > openflags is not enabled in my FSAL open2 fct. > > While capturing with tcpdump, the NFS client actually sends a > > OPEN then SETATTR with size = 0 but not ctime. > > > > By looking at an example in open_by_handle, if IIUC if the flag > > O_TRUNC is there, we refresh the attrs by calling getattrs to > > attrs_out, I do not understand that, why it does that instead of > > calling setattrs ? > > > > > > It should work (and, in fact, passes tests, so it does...) Here's > > what happens: > > > > In nfs4_op_open() It checks the attributes to set for ATTR_SIZE, and > > if that's zero, it sets FSAL_O_TRUNC in openflags. This is passed to: > > > > fsal_open2(), which does the same check, and again sets FSAL_O_TRUNC > > in openflags. If there's no name (this is an open-by-handle), > > openflags is passed to obj_ops->open2(); if there's a name, it's > > passed to open2_by_name(), which passes it to obj_ops->open(). > > Either way, it gets to: > > > > mdcache_open2() which calls mdc_open2_by_name() (if there's a name) > > which calls obj_ops->open2(), or directly calls obj_ops->open2(); in > > either case, that's calling into the FSAL with FSAL_O_TRUNC set. > > Once that returns, if that flag is set, MDCACHE invalidates the > > cached attributes for that handle. > > > > So, it looks like it should be working properly. > > > > Daniel > > > > _______________________________________________ > > 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

> Well, after a cup of coffee I double checked thing. I confirm that for a call open > with O_TRUNC flag, my NFS client (linux centos7) sends a OPEN message (do'nt > see FSAL_O_TRUNC flag propagated to open2 so may be it is not set by the > client) and a separate SETATTR message with size = 0. If the truncate comes as a separate SETATTR then everything should work just fine. The open2 call won't have FSAL_O_TRUNC, but there will be a subsequent setattr2 call with size = 0. > So I don't know how my FSAL can handle O_TRUNC within open2 function and > AWAIU since it does not return the attr changes (size and ctime) in attrs_out, > MDcache can not invalidate the cache and I'll have info inconsistency between > the backend and the mdcache theorically. I don't quite understand the issue here. MDCACHE invalidates the attributes if open2 is called with FSAL_O_TRUNC. Are you saying your FSAL wouldn't be able to handle FSAL_O_TRUNC? At worst, you have to do a setattr yourself. I do see some paths through open2 in MDCACHE where we could improve the attribute situation. We did improve on the case of mdcache_open2_by_name finding the entry in cache, I think we do update the attributes from the underlying FSAL's open2 (by handle) in that case. Frank

Well, after a cup of coffee I double checked thing. I confirm that for a call open with O_TRUNC flag, my NFS client (linux centos7) sends a OPEN message (do'nt see FSAL_O_TRUNC flag propagated to open2 so may be it is not set by the client) and a separate SETATTR message with size = 0.

So I don't know how my FSAL can handle O_TRUNC within open2 function and AWAIU since it does not return the attr changes (size and ctime) in attrs_out, MDcache can not invalidate the cache and I'll have info inconsistency between the backend and the mdcache theorically.