[Samba] locking and gfs

[Scott Lovenberg]

On Feb 9, 2008 3:01 PM, markus neis <markus.neis at googlemail.com> wrote:

> i set oplocks = yes , kernel oplocks = yes and as I said locking = yes,
> but this slows down everything
>
>

OK, from what I gather (which very well could be inaccurate), it looks like
you might be stuck on a spinlock timeout on a blocking call.

Also, if I understand the documentation correctly, when you set locking =
yes, you pass the call for a lock to the next interface layer, which will
traverse a good number of calls, and query the file system somewhere along
the way.  Samba will queue the lock with blocking locks, and check every now
and then, not continuing along with the I/O until it hears back on the lock
status.  Meanwhile the call is passed to GFS for the lock which will then
query the other node, which must make the same series of calls and send its
response back across the wire (this may not happen depending on caches, I'm
not sure), all the way back to samba who then continues if it can have the
lock.  If samba can't have the lock, this process starts all over.  That is,
once again, as I understand it.

If you set locking = no, it never gets passed to the first interface,
immediately returning a success, without ever having done the lock.  So you
ask for the lock and samba says, "You have the lock.", then I come along
asking for the same range lock and samba once again says "You have the
lock.".

from man 5 smb.conf:

       blocking locks (S)
          This  parameter  controls  the behavior of smbd(8) when given a
request by a client to obtain a byte range lock on a region of an
          open file, and the request has a time limit associated with it.

          If this parameter is set and the lock range requested cannot be
immediately satisfied,  samba  will  internally  queue  the  lock
          request, and periodically attempt to obtain the lock until the
timeout period expires.

          If this parameter is set to no, then samba will behave as previous
versions of Samba would and will fail the lock request immedi-
          ately if the lock range cannot be obtained.

          Default: blocking locks = yes

          locking (S)
             This controls whether or not locking will be performed by the
server in response to lock requests from the client.

             If  locking  = no, all lock and unlock requests will appear to
succeed and all lock queries will report that the file in ques-
             tion is available for locking.

             If locking = yes, real locking will be performed by the server.

             This option may be useful for read-only filesystems which may
not need locking (such as CDROM drives), although  setting  this
             parameter of no is not really recommended even in this case.

             Be careful about disabling locking either globally or in a
specific service, as lack of locking may result in data corruption.
             You should never need to set this parameter.

             No default

          lock spin time (G)
             The  time  in  microseconds  that  smbd should keep waiting to
see if a failed lock request can be granted. This parameter has
             changed in default value from Samba 3.0.23 from 10 to 200. The
associated lock spin count parameter is no longer used in Samba
             3.0.24. You should not need to change the value of this
parameter.

             Default: lock spin time = 200


 It would seem that you could get a bit of performance tuning GFS, but I'm
thinking that you'll also have to tune layers that GFS depends on to see
much of a difference (lower throughput for faster response from network, CPU
and memory).  There is a "gfs_tool gettune" command that will get the gfs
tunable parameters which can be set via "gfs_tool settune".  This thing
seems to cross so many layers that you'd have to tune each layer along its
path, IMHO.

I hope this was a bit helpful.  Can anyone with more low level knowledge
confirm or refute this at all?
-- 
Peace and Blessings,
-Scott.

"Of course, that's just my opinion; I could be wrong"
-Dennis Miller