7:39 a.m.
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.
Daniel