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

> 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-rTVxVC91Y7HdjGpECqA... 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.

> 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. Yea, I suppose that could be done... Someone should also edit the wiki, it refers to deprecated FSALs... The truth is we are just small enough of a community that we get distracted from updating documentation, but large enough to go off in all sorts of directions (so several active FSALs)... Frank _______________________________________________ Devel mailing list -- devel(a)lists.nfs-ganesha.org To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org