[Samba-it] Oplocks

[Simo Sorce]

On Mon, 2002-12-09 at 11:24, Giuseppe Torlai wrote:
> Sono il primo a postare?

SI!

> Se si, voglio un evento tipo gastone paperone!

eheh

> La mia domanda riguarda la gestione, con Samba, degli Oplocks.

Iniziamo subito sul pesante eh :-)

> Stiamo studiando di arrivare a sostituire servers W2k con Linux+Samba, ma
> ci siamo scornati col problema Oplocks. LLa struttura di riferimento e'
> quindi Server Linux/Samba, clients Windows da W95 a XP.
> Ho provato a vedere la documentazione, ma probablmente per la mia
> tontaggine/ignoranza non ho capito bene come maneggiarli.
> Innanzitutto i problemi. Abbiamo verificato che, se vengono messi sul
> share Samba files quali applicativi Access/caselle postali Outlook/files
> Word spesso e volentieri succedono corruzioni / files indisponibili ed
> altre robacce simili. I problemi spariscono disabilitando gli oplocks.
> Problemi che NON ci sono se uso le stesse cose su di uno share basato
> su W2k. Da questo derivo che W2k e Samba maneggiano diversamente gli
> Oplocks.
> Mi piacerebbe saperne di piu' sui metodi di gestione, se e quali files
> vanno esclusi, se esistono contrindicazioni relative alle performance.
> Ho letto ad esempio che se ho un DB Access che e' usato da piu' persone
> l'uso degli oplocks e' controproducente. A questo punto, perche' sullo
> share W2k tutto funziona?
> Esistono documentazioni in cui il problema e' affrontato in dettaglio?

Il problema degli oplocks è un po' complesso, perchè ci sono molte
variabili in gioco.
Documentazione precisa non ce n'è purtroppo, in fondo ti allego
messaggio di Jeremy Allison (l'autore del supporto in samba) che cerca
di fare un po' di chiarezza.

Legati agli oplocks spesso ci sono anche problemi con kernel Linux.
Infatti su kernel 2.4.x sono disponibili i cosidetti kernel oplocks
(introdotti sotto nostra pressione :-) che però non sono iper testati e
riteniamo ci sia qualche baco in versioni vecchie del 2.4 quando vengono
stressate. (si possono però disabilitare i kernel oplocks e mantenere un
supporto solo a livello applicativo come succede in tutte le piattaforme
che non hanno supporto per gli oplock nel kernel ovvero tutte tranne
IRIX 6.4 o 5 e linux > 2.4 :)


Come leggerai nella email che riporto in versione integrale sotto
l'oplock non è un vero locking.
Quello che fanno gli oplock è di chiedere un uso esclusivo di un file
allo scopo di poter mantenere una cache locale e non inviare updates sul
disco del server così da essere più veloce.

Quando il server rivela che un'altro processo vuole accedere al file, lo
mette un attimo in attesa e manda un oplock break al client che ha
ottenuto l'oplock chiedendogli di scrivere le modifiche.

Se qualcosa non funziona ci sono casini.

In ogni caso gli oplock si possono disabilitare anche per share in modo
da ridurre gli effetti di lentezza che si generano su alcune operazioni
se non sono attivi.

Tutto comunque di pende dal carico, ci sono moltissime situazioni in cui
gli oplock disabilitati non impattano significativamente sulle
performance.

Su w2k funziona tutto perchè MS fa test solo su w2k, e a volte capire
esattamente le semantiche utilizzate da w2k (compresi i bachi!) non è
semplice.
Comunque nel 95% dei casi abbiamo verificato che i problemi di oplock
erano dovuti a problemi di hw di rete. Se tutto è configurato
correttamente un kernel 2.4 recente (diciamo 2.4.18) e una versione
recente di samba (diciamo 2.2.7a che uscirà fra qualche giorno ;-) non
dovrebbero dare problemi neanche con i database access o foxpro.

Simo.


Segue ettera di Jeremia agli apostoli ;-)


     From: 
jra at dp.samba.org
       To: 
samba at lists.samba.org
       Cc: 
John H
Terpstra
<jht at samba.org>, Jay Ts <jay at jayts.cx>, chris at devidal.tv, Mathew McKernan <mathewmckernan at optushome.com.au>, samba at lists.samba.org, samba-technical at lists.samba.org
  Subject: 
Re: [Samba]
Re: How
Samba let us
down
     Date: 
Thu, 24 Oct
2002
17:48:49
+0000

Ok, as promised, a brief explaination of oplocks, share modes
and locking.

When a client opens a file it can request an "oplock" or file
lease. This is (to simplify a bit) a guarentee that no one else
has the file open simultaneously. It allows the client to not
send any updates on the file to the server, thus reducing a
network file access to local access (once the file is in
client cache). An "oplock break" is when the server sends
a request to the client to flush all its changes back to
the server, so the file is in a consistent state for other
opens to succeed. If a client fails to respond to this
asynchronous request then the file can be corrupted. Hence
the "turn off oplocks" answer if people are having multi-user
file access problems.

Unless the kernel is "oplock aware" (SGI IRIX and Linux are
the only two UNIXes that are at the moment) then if a local
UNIX process accesses the file simultaneously then Samba
has no way of telling this is occuring, so the guarentee
to the client is broken. This can corrupt the file. Short
answer - it you have UNIX clients accessing the same file
as smbd locally or via NFS and you're not running Linux or
IRIX then turn off oplocks for that file or share.

"Share modes". These are modes of opening a file, that
guarentee an invarient - such as DENY_WRITE - which means
that if any other opens are requested with write access after
this current open has succeeded then they should be denied
with a "sharing violation" error message. Samba handles these
internally inside smbd. UNIX clients accessing the same file
ignore these invarients. Just proving that if you need simultaneous
file access from a Windows and UNIX client you *must* have an
application that is written to lock records correctly on both
sides. Few applications are written like this, and even fewer
are cross platform (UNIX and Windows) so in practice this isn't
much of a problem.

"Locking". This really means "byte range locking" - such as
lock 10 bytes at file offset 24 for write access. This is the
area in which well written UNIX and Windows apps will cooperate.
Windows locks (at least from NT or above) are 64-bit unsigned
offsets. UNIX locks are either 31 bit or 63 bit and are signed
(the top bit is used for the sign). Samba handles these by
first ensuring that all the Windows locks don't conflict (ie.
if other Windows clients have competing locks then just reject
immediately) - this allows us to support 64-bit Windows locks
on 32-bit filesystems. Secondly any locks that are valid are
then mapped onto UNIX fcntl byte range locks. These are the
locks that will be seen by UNIX processes. If there is a conflict
here the lock is rejected.

Note that if a client has an oplock then it "knows" that no
other client can have the file open so usually doesn't bother
to send to lock request to the server - this means once again
if you need to share files between UNIX and Windows processes
either use IRIX or Linux, or turn off oplocks for these
files/shares.

Hope this is clear :-).

Jeremy.

-- 
Simo Sorce - simo.sorce at xsec.it
Xsec s.r.l.
via Durando 10 Ed. G - 20158 - Milano
tel. +39 02 2399 7130 - fax: +39 02 700 442 399
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-it/attachments/20021209/bb7c8fab/attachment.pgp>