[GEDI] [RH-nfs-ganesha] gfapi: possible approaches to get lk_owner support

[Frank Filz]

On 10/04/2017 05:36 AM, Matt Benjamin wrote:
> Hi Soumya,
>
> On Wed, Oct 4, 2017 at 7:33 AM, Soumya Koduri <skoduri at redhat.com> wrote:
>
>> As far as the locks are concerned, looks like when we close a fd, server
>> expects us to pass on lkowner as well and it cleans up locks with only that
>> lkowner. That way we are right now safe to use glfs_dup and set another
>> lkowner on the duplicate glfd returned.
>>
>> But if in case in future there comes any requirement to close all the locks
>> tied to an fd, then the locks taken on both the glfd's shall be lost.
> I've been trying to understand this precise point in the discussion.
> Are you describing the potential effect of holding POSIX fcntl locks
> in the server (as opposed to OFD locks, which I'd hope it used now, if
> it uses such locks at all!), or something else?
>
> This discussion has been very closely tied to details of the
> structures, sorry about the basic semantic questions.
>
Yea, I was going to say something about OFD locks. Definitely Gluster
should investigate using OFD locks on the underlying filesystems so it
never has to worry about losing locks. I'd be curious what it actually
does on that side to manage the locks since the Gluster daemons should
have the same issues Ganesha had about being a single process and
therefore single lock owner. Does Gluster have to run on non-Linux?

We also need to push very hard against ever implementing the broken
POSIX behavior, and if we do, allow a bypass of it with OFD locks
(though then we might need a new glfs_dup that creates a new "open file
description" in case in the process of making glfapi work more like
POSIX (unfortunate in this circumstance) it is also expected that
glfs_dup would share the open file description and thus lock owner or
something crazy like that...

Frank