[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 _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org