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, 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:
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
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.