linux cifs file locking samba server

Hi All,
Some background:
I've
been working on and off for several years to try and resolve a long
standing issue with File Locking between Linux Clients on a Samba
Server.
In short, when two linux clients mounted a share using
smbfs, then opened the same document (in OpenOffice) on a samba server,
both were given rw access, therefore the last client to save overwrites
any other changes by any other client.

Bug submitted to OOo: 
http://www.openoffice.org/issues/show_bug.cgi?id=57712

The first change suggested was to mount as cifs instead of
smbfs. This produced unpredictable results, but research and
recommendations suggested we stick with it.
Approximately 12 months ago, we finally got a major breakthrough after contacting Andrew Bartlett @ Samba directly:
"From my research it would appear that the current 
2.6.17-rc5
has the client support the the locking you need, and Samba 3.0.23rc1 has
the server half."
Tested
using the versions suggested with Openoffice 2.0, and it worked!
...sort of. This time we didn't lose any data, however the error
reporting by OpenOffice is still very poor (I know this probably isn't
the cifs project responsibility, however I'm hoping you can help me
construct a good bug report for the ooo team). There were also a few
unpredictable results with the way oplocks were managed on the server -

Specific setup:
Clients: Debian Sid, 2.6.18 kernel, Openoffice 2.0.4
Server: Red Hat Enterprise Linux ES release 4, 2.6.9-22.0.2.ELsmp kernel, samba 
3.0.23c-4

Scenario 1:
When
two clients open a file but don't save changes, the second client gets
OpenOffice reporting that the file needs to be repaired, then fails in
the repair process.
smbstatus with client 1 only accessing the file:
11143       
1158       DENY_NONE  0x12019f    RDWR       EXCLUSIVE       
/samba/it   Bernard/OpenOffice/test.ods   Fri Nov 24 08:49:58 2006

smbstatus when client 2 tries to access the file - note the oplocks changed from EXCLUSIVE to NONE for client 1
11143       
1158       DENY_NONE  0x12019f    RDWR       NONE            
/samba/it   Bernard/OpenOffice/test.ods   Fri Nov 24 08:49:58 2006
11116       
1003       DENY_NONE  0x120089    RDONLY     NONE            
/samba/it   Bernard/OpenOffice/test.ods   Fri Nov 24 08:50:30 2006


Scenario 2:
A
client opens a document, makes a change and saves, OpenOffice throws an
error "Could not create backup copy" and doesn't save. Clicking save
again saves the document.
Examining the smbstatus output on the server, before clicking save:
11116       
1003       DENY_NONE  0x12019f    RDWR       EXCLUSIVE       
/samba/it   Bernard/test2.odt   Thu Nov 23 16:28:48 2006

smbstatus after receiving the "Could Not create backup copy" error - note the oplock has changed from EXCLUSIVE to NONE :
11116       
1003       DENY_NONE  0x12019f    RDWR       NONE            
/samba/it   Bernard/test2.odt   Thu Nov 23 16:28:48 2006

smbstatus after clicking [OK] on error and clicking save again - Note the oplock changed back to EXCLUSIVE:
11116       
1003       DENY_NONE  0x12019f    RDWR       EXCLUSIVE       
/samba/it   Bernard/test2.odt   Thu Nov 23 16:32:14 2006


Scenario 3:
As
in Scenario 2, except a second client tries to open the file after the
first client has received the "Could not create backup copy" error (ie
oplock set to NONE for client 1)
The second client is presented with
a filter selection dialog by openoffice - choosing the correct filter
throws an error "test2.odt is corrupt and therefore cannot be opened.
Should OpenOffice repair the file?". The repair then fails

Examining smbstatus while the filter dialog is open:
11116       
1003       DENY_NONE  0x12019f    RDWR       NONE            
/samba/it   Bernard/test2.odt   Thu Nov 23 16:32:14 2006
11143       
1158       DENY_NONE  0x120089    RDONLY     NONE            
/samba/it   Bernard/test2.odt   Thu Nov 23 16:34:42 2006

After
the first client clicks [OK] on the "Could not create backup copy"
dialog, the second client OKs all error messages - smbstatus output:
<none>

Now the second client can reopen the file and edit/save it, and effectively steal the rw lock from the first client.

smbstatus after the second client steals the lock from client 1:
11156        1182       DENY_NONE  0x120095    RDWR      
EXCLUSIVE        /samba/it   Bernard/test2.odt   Thu Nov 23 16:35:47 
2006

When
the first client now tries to save, "Could not create backup copy"
dialog appears, click OK, the save icon greys out and stays greyed out
despite making further changes. If client 1 tries to save, the document
then changes it's mode to (read only). This implies that getting a
document to open (read only) is possible, and OpenOffice can behave
correctly - it's just that it's not doing it right from the start.

As you can see, there are some fairly unpredictable results here. I see
this as a serious useability bug, but it's quite difficult to explain,
and even more difficult for me to pinpoint where the error is
occurring.


Ideally, I'd like to see the following occur:
The
first client opens the document and is given the rw lock, the second
and subsequent clients open the document and are granted a ro lock for
viewing only. It would even be nice if the client could query the
server for which user holds the rw lock and return that to the clients
with ro locks.
The rw lock should be released if the first client closes the document, or changes the mode in OpenOffice to read-only.


I'm
not sure whether there's the possibility of data loss - you could
certainly see in scenario 3 that after client 1 loses it's rw lock then
continues editing that they will be forced to manually merge their
changes with client 2's changes, but I'm not sure if I can create a
scenario where data will actually be overwritten. Note that I have
tested this with koffice (kwrite specifically), and the original issue
of clients overwriting each others changes appears.

At this stage it is holding up further rollouts of Linux to the desktops (stalled at ~35% of the desktop fleet).

I
work for an Australian company (I believe a few of the core samba team
members are also Australian), and we will certainly consider
contracting samba developers to fast track an investigation and
resolution if this is a possibility. 

If anyone has any suggestions/fixes/info/links/requests for more info/etc I will happily provide.

My apologies for the long post, if there's a better place for this, please let me know. 

Thanks,

Bernard Gray
_______________________________________________
linux-cifs-client mailing list
linux-cifs-client@xxxxxxxxxxxxxxx
https://lists.samba.org/mailman/listinfo/linux-cifs-client