fsal_close old and new API
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
On 07/11/2018 04:44 AM, ntvietvn@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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@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
On 07/11/2018 04:44 AM, ntvietvn@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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@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-rTVxVC91Y7HdjGpECqAW-G... 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. Frank
On 07/11/2018 10:24 AM, Frank Filz wrote:
On 07/11/2018 04:44 AM, ntvietvn@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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@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-rTVxVC91Y7HdjGpECqAW-G...
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. Daniel
On 07/11/2018 10:24 AM, Frank Filz wrote:
On 07/11/2018 04:44 AM, ntvietvn@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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@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
Thanks Daniel & Frank, I'll take a look at the doc Viet On Wed, Jul 11, 2018 at 5:04 PM, Frank Filz <ffilzlnx@mindspring.com> wrote:
On 07/11/2018 04:44 AM, ntvietvn@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
*/ 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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@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
On 07/11/2018 10:24 AM, Frank Filz wrote: platforms. 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@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
participants (4)
-
Daniel Gryniewicz -
Frank Filz -
ntvietvn＠gmail.com -
Tuan Viet Nguyen