1:42 p.m.
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().
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>