Locking, notify collisions using CTDB on non-clustered share?
Christopher R. Hertel
crh at samba.org
Sat Apr 14 15:57:26 UTC 2018
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. :-)
More information about the samba-technical