> I am a little confused, can you end up with 2 objects if you use openat() like > FSAL_VFS does? > Why does FSAL_VFS has a merge() method implementation. > If I change FSAL_GPFS to use openat() do I need to implement merge() ?
So here is the scenario: We have two OPEN RPC calls for the same file (need not be create). The file is currently not in mdcache, so both resolve to open2() calls by name. The FSAL performs each open (not necessarily aware of the other), and since it's by name, the FSAL must allocate and fill out an fsal_obj_handle. Then MDCACHE calls mdcache_new_entry. Obviously, one of the threads gets there first and instantiates a cached fsal_obj_handle. The second thread discovers there is already a cached entry for the same handle, however, since the 2nd thread ALSO has share state in its fsal_obj_handle, we cannot just discard the 2nd fsal_obj_handle, so a call to merge() is made to merge the share state. It is possible the 2nd share state is in conflict with the first, so that can result in a call to close2() to discard that share and return the conflict. An FSAL that can fully implement share reservations in it's filesystem call would at least avoid the case of having to unwind a conflicting open (since the open would have failed before the fsal_obj_handle was created, but it would still have to merge compatible share reservations). Note that prior to support_ex, this race could still happen, but since there was no "state" in the fsal_obj_handle, we just discarded the 2nd fsal_obj_handle. There are other paths to get to this race. Pure lookups can race of course, however they don't have share reservation state. Even two PUTFH could tace. An NFS v4 OPEN by handle could also find a way to race and need a call to merge(). It's also possible an FSAL might have other stuff in its private fsal_obj_handle that might need to be merged when this race occurs. Frank > From: "Frank Filz" <ffilz...@mindspring.com> > To: "'nfs-ganesha-devel'" <nfs-ganesha-devel@lists.sourceforge.net> > Date: 09/22/2016 04:33 PM > Subject: [Nfs-ganesha-devel] Support_ex Oops... > > > > Crud, while working on the documentation for support_ex, just came across > a > method other folks implementing support_ex missed... > > There is the possibility that two open2() calls to open by name will race, > resulting in two fsal_obj_handle's being created. When the MDCACHE > attempts > to cache the 2nd entry, it will detect a collision, and then it needs to > fix > things up so the 2nd object handle can be released. > > The FSAL is expected to implement the merge() method to accomplish > merging > the share reservations. > > FSAL_GLUSTER, FSAL_GPFS, and FSAL_RGW do not implement this > method... > > Which means the default that does nothing will be called. This will result > in the 2nd share reservation being dropped... > > This is not good... > > Frank > > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus > > > ---------------------------------------------------------------------------- -- > _______________________________________________ > Nfs-ganesha-devel mailing list > Nfs-ganesha-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel > > > --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ------------------------------------------------------------------------------ _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
