11:47 a.m.
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-rTVxVC91Y7HdjGpECqA...
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(a)mindspring.com>
Cc: devel(a)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(a)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