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 ? Thank you. Viet
On 08/07/2018 01:03 PM, 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
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@redhat.com> wrote:
On 08/07/2018 01:03 PM, 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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
FSAL_GPFS sets O_TRUNC on the open, so the file should be truncated as part of the open. Frank From: Tuan Viet Nguyen [mailto:ntvietvn@gmail.com] Sent: Tuesday, August 7, 2018 10:36 AM To: dang@redhat.com Cc: devel@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] Re: O_TRUNC in open2 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@redhat.com <mailto:dang@redhat.com> > wrote: On 08/07/2018 01:03 PM, ntvietvn@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@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>
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@redhat.com <mailto:dang@redhat.com>> wrote:
On 08/07/2018 01:03 PM, ntvietvn@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@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>
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@redhat.com <mailto:dang@redhat.com>> wrote:
On 08/07/2018 01:03 PM, ntvietvn@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@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>
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
Thanks Daniel and Frank for those details, I've just read the mdcache and indeed it uses attrs_out to invalide the cache. Thank you On Tue, Aug 7, 2018 at 9:03 PM, Frank Filz <ffilzlnx@mindspring.com> wrote:
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@redhat.com <mailto:dang@redhat.com>> wrote:
On 08/07/2018 01:03 PM, ntvietvn@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@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>
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
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.
If the client is sending a separate SETATTR to set the size to 0, then open2 definitely won't get the FSAL_O_TRUNC flag (we treat each NFS4 op in a compound separately).
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 ?
Hmm, MDCACHE should use attrs_out to refresh the attributes on open_by_handle if they are valid. I'm not quite sure about the reference to setattrs. It is assumed that the FSAL will handle FSAL_O_TRUNC in the open2 call (even if IT needs to do a separate setattrs from its open call). Frank
Hello again, 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. Can you advice? Thank you
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
Sorry, let me rephrase I wanted to know in case where o_trunc is interpreted as 2 separate messages, as FSAL_O_TRUNC is not enabled, how does the mdcache get notification to invalide cache? Thank you I suppose that Le mer. 8 août 2018 à 17:33, Frank Filz <ffilzlnx@mindspring.com> a écrit :
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
setattr() always triggers a cache refresh. Daniel On 08/09/2018 11:06 AM, Tuan Viet Nguyen wrote:
Sorry, let me rephrase I wanted to know in case where o_trunc is interpreted as 2 separate messages, as FSAL_O_TRUNC is not enabled, how does the mdcache get notification to invalide cache?
Thank you
I suppose that
Le mer. 8 août 2018 à 17:33, Frank Filz <ffilzlnx@mindspring.com <mailto:ffilzlnx@mindspring.com>> a écrit :
> 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
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
I guess I’m still confused. If client sends OPEN and SETATTR size = 0 separately, then open2 will just open the existing file (or create new one if it was an OPEN/CREATE), setattr will then set the size to 0. mdcache_setattr2 then refreshes the attributes. In the case of open2 called with FSAL_O_TRUNC, I think also the attributes either get refreshed or invalidated. Are you seeing a specific issue? It sounds like you are working on your own FSAL. You may want to read https://docs.google.com/document/d/1pOpN7Ea3zK4Yf5aIK-rTVxVC91Y7HdjGpECqAW-G... to make sure you aren’t missing something about the API (though that hasn’t been updated, so there is surely 2.7 stuff not covered, and maybe even 2.6). What Ganesha code base are you working on? Further, you may wish to join us on FreeNode IRC #ganesha channel. Frank From: Tuan Viet Nguyen [mailto:ntvietvn@gmail.com] Sent: Thursday, August 9, 2018 8:07 AM To: Frank Filz <ffilzlnx@mindspring.com> Cc: devel@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Devel] Re: O_TRUNC in open2 Sorry, let me rephrase I wanted to know in case where o_trunc is interpreted as 2 separate messages, as FSAL_O_TRUNC is not enabled, how does the mdcache get notification to invalide cache? Thank you I suppose that Le mer. 8 août 2018 à 17:33, Frank Filz <ffilzlnx@mindspring.com <mailto:ffilzlnx@mindspring.com> > a écrit :
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
Thanks, "setattrs refreshes the cache" answered my question. And there is no specific issue related to this question. I'm working with ganesha 2.5.4. Have a good day Le jeu. 9 août 2018 à 18:47, Frank Filz <ffilzlnx@mindspring.com> a écrit :
I guess I’m still confused.
If client sends OPEN and SETATTR size = 0 separately, then open2 will just open the existing file (or create new one if it was an OPEN/CREATE), setattr will then set the size to 0. mdcache_setattr2 then refreshes the attributes.
In the case of open2 called with FSAL_O_TRUNC, I think also the attributes either get refreshed or invalidated.
Are you seeing a specific issue? It sounds like you are working on your own FSAL. You may want to read https://docs.google.com/document/d/1pOpN7Ea3zK4Yf5aIK-rTVxVC91Y7HdjGpECqAW-G... to make sure you aren’t missing something about the API (though that hasn’t been updated, so there is surely 2.7 stuff not covered, and maybe even 2.6).
What Ganesha code base are you working on?
Further, you may wish to join us on FreeNode IRC #ganesha channel.
Frank
*From:* Tuan Viet Nguyen [mailto:ntvietvn@gmail.com] *Sent:* Thursday, August 9, 2018 8:07 AM *To:* Frank Filz <ffilzlnx@mindspring.com> *Cc:* devel@lists.nfs-ganesha.org *Subject:* [NFS-Ganesha-Devel] Re: O_TRUNC in open2
Sorry, let me rephrase
I wanted to know in case where o_trunc is interpreted as 2 separate messages, as FSAL_O_TRUNC is not enabled, how does the mdcache get notification to invalide cache?
Thank you
I suppose that
Le mer. 8 août 2018 à 17:33, Frank Filz <ffilzlnx@mindspring.com> a écrit :
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
participants (4)
-
Daniel Gryniewicz -
Frank Filz -
ntvietvn＠gmail.com -
Tuan Viet Nguyen