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> wrote:
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