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

[Christopher R. Hertel]

Below...

On 04/23/2018 03:13 PM, Jeremy Allison wrote:
> On Sat, Apr 14, 2018 at 08:10:48PM -0500, Christopher R. Hertel via samba-technical wrote:
>> So...
>>
>> The vfs_fileid module helps.  I'm using the fsid algorithm and that has
>> resolved several of the errors that were being generated.
>>
>> ...but not all of them.  I have found that I also need to change the share
>> path so that the non-clustered shares each have different paths.
>>
>> For example:
>>
>> Node | ShareName | Path
>>  1   | EXT4-1    | /mnt/ext4/sambaShare
>>  2   | EXT4-2    | /mnt/ext4/sambaShare
>>
>> With that setup, when I run the smb2.notify torture test, I get errors like
>> this:
>>   ERROR: nchanges=1 action=2 expectedAction=3 filter=0x00000020
>> and this:
>>   (../source4/torture/smb2/notify.c:437) wrong value for
>> notify.smb2.out.num_changes  0x14 should be 0x9
>>
>> These are generated when I run smbtorture against both shares _at the same
>> time_.  There is a certain randomness involved, of course, but these or
>> similar errors are generated quite reliably with this configuration.
>>
>> All I have to do is change the paths to:
>>
>> Node | ShareName | Path
>>  1   | Node-1    | /mnt/ext4/sambaShare-1
>>  2   | Node-2    | /mnt/ext4/sambaShare-2
>>
>> (...making sure, of course, that those directories exist).  Now the errors
>> magically disappear.  (Well, there are some "change_time not setup" but
>> these also occur on a non-clustered, single instance server so I assume that
>> they are "normal").
>>
>> So it seems that the lookup key for Change Notify events is the full local
>> pathname, not dev/inode.
> 
> Yes, that's true. ChangeNotify is pathname based, not inode based.
> 

Jeremy:  Thanks for the confirmation.  Quite helpful.

Changing the paths *and* using fileid:fsid in combination has cleared up
most of the errors we were seeing.  I have one new SHARING_VIOLATION error
I'm looking into.  Again, it's on the non-clusered EXT4 share, so it doesn't
interfere with the cluster we are running, but it does mess with our
testing.  I'm digging into it a will let folks know if there are any other
changes that are needed in order to run a mixed-mode cluster.

Thanks!

Chris -)-----