[NFS-Ganesha-Devel] Re: fsal_close old and new API

On 07/11/2018 10:24 AM, Frank Filz wrote: >> On 07/11/2018 04:44 AM, ntvietvn(a)gmail.com wrote: >>> Hello, >>> >>> While reading the fsal_remove function, it seems that there may be a >>> missing check before calling fsal_close(), if the FSAL supports new >>> API or not >>> >>> /* Make sure the to_remove_obj is closed since unlink of an >>> * open file results in 'silly rename' on certain platforms. >>> */ >>> status = fsal_close(to_remove_obj); >>> >>> So even if the FSAL tells the SAL that support_ex = true, it still >>> needs to >> implement the op->close function which is a little bit strange. >>> >>> Can you shed some light on this point? >>> >>> Thank you >>> _______________________________________________ >>> Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe >>> send an email to devel-leave(a)lists.nfs-ganesha.org >>> >> >> >> fsal_close() and the close() API are still used to close the global file descriptor. >> I'm not sure if this has been explained before, so if you've heard >> it, just skip to the end. >> >> In NFS, there are two types of operations that operate on an FD: >> anonymous, and explicit open. NFSv4 added an explicit open to the >> protocol, which allows the client to get a special state ID that corresponds to an open file. >> This allows things like exclusive open modes, and allows the client >> to better reclaim open state on a restart or failover. Supporting >> this necessitated a new API in Ganesha, the >> support_ex() API. It added open2()/close2(), which can take a >> state_t argument for the explicit-open cases. It also added new APIs >> for each file op that works on an FD, so that they can take an >> optional state_t to represent the FD to operate on. >> >> However, NFSv3 doesn't have explicit-open, and NFSv4 allows anonymous >> I/O without an open, if the client so desires, so FSALs still need to >> have a concept of a global FD that can be used as a catch-all for >> cases where explicit-open isn't used. To simplify the code a bit, >> the close() call was kept, to handle closing the global FD, since this is a complicated case, and is used in lots of code. >> >> TL;DR, a FSAL still needs both close2() for explicit-open, and >> close() for global FD. > > It's not well advertised, but there is some documentation here: > > https://docs.google.com/document/d/1pOpN7Ea3zK4Yf5aIK- rTVxVC91Y7HdjGpE > CqAW-Gcd4/edit?usp=sharing > > Someone should link this from our wiki :-) > > Since that document may not cover every little subtlety we have found, I welcome folks to request access to comment or even edit. > Or better yet, copy it into the wiki where the community can edit it.