10:33 a.m.
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