Few technical questions

Antun Horvat mail at antun-horvat.from.hr
Sun Jun 29 12:33:09 MDT 2014

Thank you for your reply.

On 06/29/2014 08:07 PM, Volker Lendecke wrote:
> On Sun, Jun 29, 2014 at 05:29:37PM +0200, Antun Horvat wrote:
>> Does the Samba oplock code works? I have read a mailing list and
> Yes. We have a very comprehensive oplock test suite that we
> run before every checkin. Oplocks always have the problem of
> potential data coherency problems when network problems
> occur. So without oplocks you're always safer, regardless of
> whether the server is Samba, Windows, NetApp or something
> else.
I did not know that. It's just that we had a windows 2000 server around 
for about ~10 years and we had never seen any issues with it regarding 
any kind of corruption. Now whey I've switched to Samba 4.1 I'm 
experiencing many tiny issues which at some times result in file 
destruction. Since this is so random I can't catch and reproduce any of 
these issues.
>> found many occurrences of corrupted MS Office files and the
>> resolution of that was to disable oplock code. I find it hard to
>> believe it that Samba after all those years did not manage to fix
>> the oplock code, and at least write few unit tests that emulate MS
>> office behavior.
>> What are proper socket timeout defaults? In few cases I had a small
> We use the default TCP timeouts of the OS kernel. In case
> you are running Linux, you might play with the TCP_KEEPCNT,
> TCP_KEEPIDLE and TCP_KEEPINTVL socket options to match your
> needs. See "man 7 tcp" for documentation on these options.
I understand that, but wouldn't it be more logical if you had set 
Windows OS defaults so that less experienced (windows) admins don't have 
to bother with that?.
>> network glitch which resulted in MS clients reconnect to FS server
>> via new socket, but Samba for some reason for a long time kept the
>> old smbd process opened and as a result a client was not able to
>> open a file until I manually killed the stale smbd process. After
>> that I have set the  'reset on zero vc' to yes and these issues went
>> away.
>> Why isn't this property by default set to yes, and why aren't socket
>> options set to values that are matching Windows ones?
> "reset on zero vc = yes" is dangerous for clients behind a
> masquerading NAT device, that's why we don't enable it by
> default.
>> Is there an ability to a byte range lock via libsmbclient, since I
>> would like to write a distributed test suite for Samba FS that would
>> test
>> oplock code and maybe finally stabilize it.
> No, libsmbclient does not allow fine-grained control of
> locks. If you want to dive into extending our oplock test
> suite, I would recommend to download the Samba source code
> and take a look at source4/torture/raw/oplock.c.
> With best regards,
> Volker Lendecke
Ok, I'll look into it and see if I could help in some way.

More information about the samba-technical mailing list