Bug 200759 - Samba (CIFS) lock recovery after a failover.
Samba (CIFS) lock recovery after a failover.
Status: CLOSED CANTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: samba (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Abhijith Das
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-07-31 11:02 EDT by hoa duy dao
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-01-01 08:17:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description hoa duy dao 2006-07-31 11:02:19 EDT
Description of problem:
After a service failover, Samba (CIFS) locks are not reserved.  Also (Windows) 
clients who previously owned the locks are not notified about the Samba service 
failover.  A new client can acquire the same lock, thus data corruption might 
occur.

I think this bug is more on the Samba side.  One of your colleague, 
john.devereaux@redhat.com, has asked me to log this bug.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Lon Hohberger 2006-08-02 13:49:35 EDT
Samba lock failover / recovery is partially a limitation of the CIFS protocol. 
As I understand it, locks are connection based and tied to the connection. 
After a failover, the connection is lost - therefore, so are the locks
associated with the connection.  Clients are expected to reacquire all locks
after reconnecting, which might not be directly possible if they are blocked in
I/O with a lock held at the time of a failover.  If a layer under an application
reconnects transparently and the application is not notified to reacquire
any/all locks, then the application will assume state is okay and proceed,
potentially causing data corruption if another application acquired a lock after
the failover.

The connection/lock association makes implementation of transparent lock
failover itself fairly difficult.  I had attempted to write a howto based on
storing lock information on shared storage so that it might retrieve the lock
information, which is what several other Open Source projects do.  This is,
however inadequate.  That there is no reclaim protocol for locks similar to the
NLM reclaim protocol for NFS[1], or at least, I am not aware of any.  Even some
proprietary vendors do not claim Samba lock failover in their expensive
solutions[2].

There are, however, several ideas[3] on how to make Samba work more reliably in
high availability environments.



1. http://www.opengroup.org/onlinepubs/009629799/chap11.htm
2. http://docs.hp.com/en/B8725-90021/ch06s05.html
3. http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/SambaHA.html
Comment 2 Andrew Bartlett 2007-01-01 08:17:59 EST
Indeed.  This bug calls for protocol extensions, client updates, and should be
considered in that context (ie, not going to happen...).

I'm marking this as CANTFIX, as I think that's the best description.

Note You need to log in before you can comment on or make changes to this bug.