Samba-4.0.0-alpha14 grants oplock level II to the first client while the second keeps byte-range lock on this file. So, this causes the error with page reading in cifs kernel client (with newly introduced strict cache mode that haven't merged yet). A attached the capture, it's main points are following: 1) client_1 opens file - gets exclusive oplock on 0x0001 fid (#15) 2) client_2 opens file - gets oplock level II on 0x0002 fid (#22) 3) client_1 gets oplock break on 0x0001 - gets oplock level II (#19) 4) client_2 locks file from 1 to 2 on 0x0002 fid (#24) 5) client_1 and client_2 get oplock breaks - no oplock (#26-30) 6) client_1 opens file - gets oplock level II on 0x0003 fid (#36) - ERROR!!! 7) client_1 fails on pagereading - according to oplock level II - pagereading is ok I looked through Samba sources and didn't find any lock-specific checks while granting oplocks (for Samba-3.6 and for Samba-4.0.0 stable branches code). So, I can't reproduced it with Samba-3.6 but it may depend on a situation.
Created attachment 6207 [details] Capture from the description
Created attachment 6219 [details] Script that reproduces the problem
smb.conf: # Global parameters [global] server role = domain controller workgroup = TESTGROUP realm = test-name netbios name = TEST setup directory = setup/ [netlogon] path = /usr/local/samba4/var/locks/sysvol/localhost/scripts read only = No [sysvol] path = /usr/local/samba4/var/locks/sysvol read only = No [test] path = /mnt/samba_share read only = No
Quick question: Does this also happen with 3.5.6 on the server side? Thanks, Volker
Is the problem more client or server related? If server related then a problem is the fact, that s4's file server at the moment is unmaintained. That means, each time if possible, please try using s3 or somewhat else (on another server) for this purpose. Newer s3 winbind daemons should be working against s4 therefore there shouldn't be integration problems. But if you are keen to write a patch then we will happy to apply it. We are working to allow s3's file server to be run on top of s4 (or vice versa) but till now no adaption/approach has made it to an end yet.
(In reply to comment #4) > Quick question: Does this also happen with 3.5.6 on the server side? > > Thanks, > > Volker > I can't caught it with Samba-3.5.6 in both cases: with 'kernel oplocks = no' (to enable level2 oplocks) and without it (level2 oplocks are disabled); and it's behaviour was ok.
(In reply to comment #5) > Is the problem more client or server related? it's server related.
I caught this bug with Samba-3.6 - so, it's not a Samba-4.0.0 specific bug. I suggest to move the discussion to https://bugzilla.samba.org/show_bug.cgi?id=7928. *** This bug has been marked as a duplicate of bug 7928 ***
(In reply to comment #5) > But if you are keen to write a patch then we will happy to apply it. > I wrote the patch that fixes the problem for Samba-4.0.0-alpha14: http://git.etersoft.ru/people/piastry/packages/?p=samba4.git;a=commitdiff;h=f5e27f15c653071b257b22dc1dca9f46491cd6dd
Okay, then let us reopen this. I'm adding metze for a patch review. Metze, could you do the review and merge this if it's fine?
If this gets braces: + if (count != 0) + oplock_level = OPLOCK_NONE; I think the patch is fine as long as it passes make test.
(In reply to comment #11) > If this gets braces: > > + if (count != 0) > + oplock_level = OPLOCK_NONE; > > I think the patch is fine as long as it passes make test. > It passes samba4.raw.oplock test with new test that shows this bug http://git.samba.org/?p=samba.git;a=commitdiff;h=f453235ce057339a69398f5c862fdd3e46bd31c4 As for braces - should I respin the patch with new version?
Yeah, please do! (In reply to comment #12) > > As for braces - should I respin the patch with new version? >
Respin the patch with braces around count variable check: http://git.etersoft.ru/people/piastry/packages/?p=samba4.git;a=commitdiff;h=d02f3542a8ffc49c1250c15c2ef21748d2abea8b
Metze would you or should I push the fix?
Patch should soon land in "master".