Yea, I suppose that could be done...> 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.
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