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-Gcd4/edit?usp=sharing 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