As I understand it, concurrent access from SMB clients and NFS clients (or other UNIX processes) can cause corruption when oplocks is turned on (unless your UNIX supports kernel oplocks and you use them - only some Linux and Irix versions support them I believe). Turning off oplocks might reduce performance but prevents the possibility of corruption in this way. So having oplocks on often introduces the possibility of file corruption.

Similarly, record locks and share mode locks from SMB clients are both ignored by NFS clients/other UNIX processes (with the possible exception of newer Linux systems, they might actually enforce share mode locks). In theory this could also cause corruption, although in practice it is almost never an issue.

This next statement from John Terpstra seems a bit strong to me, see the counter example below from just a few weeks ago. Not to badmouth John, or Samba, just to add some more information to the conversation.

Regards,
Marc

John H Terpstra wrote:
Jay,

For the record, I thouroughly test samba pre-releases before we ever ship.
To the best of my knowledge, NOT ONE version of samba we have released
ever CAUSED (or resulted in) file/data corruption. If I sound defensive -
that's is exactly correct because file corruption is a DEATH issue!
What about this message posted to the samba mail list, it seems to imply that Samba did cause file corruption for him and Jeremy seems to acknowledge that it was a valid problem:

-------- Original Message --------
Subject: Re: [Samba] File corruption with write cache enabled - patch included
Date: Thu, 3 Oct 2002 18:20:01 +0000
From: [EMAIL PROTECTED]
To: Rasmus Borup Hansen <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]>

On Thu, Oct 03, 2002 at 12:52:10PM +0200, Rasmus Borup Hansen wrote:
> I recently found out that write caching in samba sometimes leads to
> file corruption (the setup program for Sophos Antivirus generates
> corrupted files when making a "central installation" on a Samba
> share).
>
> This morning I tracked down the place in the Samba code that leads to
> corruption. Here is what happened to me:
>
> "write cache size" is 8192 bytes. A client opens a new file and writes
> byte no. 30959. This byte is cached. Then the program write byte
> no. 61919 which is written directly to the disk, since the cache
> doesn't go that far. The client then writes bytes no. 0 through
> 61920. Since these bytes don't fit into the cache they are written
> directly to the disk. However, the cached byte at position 30959 is
> not discarded. When this byte is later written to the disk, the file
> will get corrupted.
>
> The patch below detects this situation and discards the cached
> byte(s). I guess that some profiling code should also be added at some
> time. The patch is against version 2.2.5.
>
> Perhaps you should warn users of current versions against using write
> caching.
>
> I believe that this bug is the same as bug no. 24502 submitted by
> Henrik Qwinto <[EMAIL PROTECTED]>.
>
> Best regards, and thank you for making Samba,

Damn good call ! Very good bugfix. I've committed it to all
Samba branches. Thanks a *lot* for this fix !

Jeremy.

--
To unsubscribe from this list go to the following URL and read the
instructions: http://lists.samba.org/mailman/listinfo/samba


Reply via email to