[Samba] Antw: Re: STATUS_SHARE_VIOLATION when Read while Write on GPFS + CTDB

Alexander Gast Alexander.Gast at WDR.DE
Wed Jun 10 02:28:15 MDT 2015


Good morning,

first of all: Thanks so far.
I've forwarded your mail to the vendor of this software an one of them
assures that their modules aren't requesting full access to those
files.

His suggestion is to set the following parameters to the share:

oplocks = no
blocking locks = no
fake oplocks = no
locking = no
strict locking = no
shares modes = no


Some of them are already set, others are "no" as default.
The only difference seems to be the "locking = no" parameter.
I'm really carefully setting this parameter because of the possibility
of data corruption. Is it wise to set this parameter?
(In the tutorial at the wiki it's explicitly set to "yes")

The whole oplocks, locking and sharemodes configuration is confusing.
The IBM recommendation from Michael Jahn is the following:

oplocks = yes (isn't explicitly set, so I assume it's default)
kernel oplocks = no
level2 oplocks = yes
strict locking = yes
posix locking = no
gpfs:sharemodes = yes
gpfs:leases = yes
gpfs:dfreequota = yes
gpfs:prealloc = yes


It seems that there are many possibilities of configure the whole
locking.
How can I determine which configuration is best for me?

In general the files are created / uploaded via SMB, and then some
other tools access this video-file to create a lower resolution
video-file and some "keyframe"-images. Those other tools are in some
cases SMB clients, in other cases GPFS client machines and the files are
gernerally accessed in "while" mode - to achieve nearly "real time
prcoessing".

I'll test some variations of the config files tomorrow morning - but it
would be very helpful to get a "best practice" config.

I really hope to be able to close this topic with a solution that
smoothes the vendors / companies.

Thanks for the help till this point and regards,
Alex Gast


-- 
Westdeutscher Rundfunk
IT-Services
Rechenzentrum
An der Rechtschule 4
Archivhaus 1145
50667 Köln
Telefon +49 (0)221 220 6496

alexander.gast at wdr.de
www.wdr.de


>>> Volker Lendecke <Volker.Lendecke at SerNet.DE> schrieb am 05.06.2015
um 11:26:
> 
> Those sharing violations are real, that works as designed
> for SMB. Applications can request to open files exclusively,
> and that is what happens here. See for example
> 
> [2015/06/05 09:49:34.398654, 10, pid=64463, effective(1901, 1901), 
> real(1901, 0)] ../source3/smbd/open.c:1082(share_conflict)
>   share_conflict: check 1 conflict am = 0x120196, right = 0x6, sa =
0x1, 
> share = 0x2
> [2015/06/05 09:49:34.398734, 10, pid=64463, effective(1901, 1901), 
> real(1901, 0), class=locking]
> ../source3/locking/locking.c:652(share_mode_stale_pid) PID 0:27594
(index 0 
> out of 1) still exists
> 
> Those messages are from SMB only, gpfs:sharemodes=no will
> not help here. You should look into your applications to see
> why they request exclusive access to files.
> 
> With best regards,
> 
> Volker Lendecke


More information about the samba mailing list