Locking, notify collisions using CTDB on non-clustered share?

[Christopher R. Hertel]

On 04/14/2018 01:31 AM, Volker Lendecke wrote:
> On Fri, Apr 13, 2018 at 02:01:12PM -0500, Christopher R. Hertel via samba-technical wrote:
>> Sounds like a plan.
>>
>> If that fixes it...  I'll still want to talk about how this all works
>> internally in June at the conference.  Thanks for the clue!
> 
> We only have one locking.tdb, indexed by node/device/inode. We have to
> make sure that if you share the same file space via different shares
> you don't mess up locking. Ralph's proposal fakes up the device on a
> per-node basis. This is not 100% bullet proof, as it's based on a hash
> into a uint64, but it might help you. The good thing is that this is
> per share.

Understood and agreed.

Also, one limit to the hostname algorithm is that it only works on a single
non-clustered share.  If there are two non-clustered shares, they would wind
up with the same device id.

One thought I had was to add an algorithm to vfs_fileid that would allow a
fixed device number to be assigned to a share, or combine a fixed part with
the hostname hash.  Another option I am considering would be to use
gethostid(3) instead of hostname, though there are some cross-platform
issues to consider there.

I'm doing some additional testing today.  The node/device/inode tuple isn't
the only key used.  In some of my earlier tests, I found that if the full
path to an object was the same across two machines I would see errors.
Those errors would magically disappear if I simply changed the name of the
directory to which the share was pointing.

I'm going to see if I can reproduce those errors even with vfs_fileid loaded.

Full disclosure:  I'm testing on Samba 4.6, which does not include the
hostname algorithm in vfs_fileid.  I'm using the fsid algorithm instead, but
it does seem to be working and it does support multiple non-clustered
shares, unlike the hostname algorithm.

Oh... and we're having a marvelous last-blast of winter snowstorm, so I'm
stuck inside anyway.  Might as well enjoy some computer time.  :-)

Chris -)-----