On Wed, 2002-12-18 at 09:52, Bob Puff@NLE wrote: > If Samba is corrupting the data files, then why wouldn't this be turned OFF by > default? I would think data corruption would be a major, MAJOR problem, and > reduce the usability of Samba. Is this really true?
It comes down to the fact that Samba is faithfully mimicking a Windows NT/2000 server. Windows NT and Windows 2000 servers *BY DEFAULT* also have OPLOCKS enabled. Oplocks provide a *SIGNIFICANT* performance boost for network file operatings when a single user is accessing a file. They allow the *CLIENT* machine to basically cache the file locally, just like caching a local file on a local hard drive. Writes to the file are cached as well. Where oplocks cause problems is when a second client wants to open the same file (as in a shared file database). Then the Samba/NT/2000 server must issue what is called an 'oplock break request' to the first client that has oplocks on the file. The client is supposed to then flush any changes to disk, and release the oplocks on the file. The server must then wait on this to happen before the second client can be granted access to the file. Problems arise when the client takes too long to respond, or fails to respond to the oplock break request from the server. The second client sees a long delay in opening the file. Furthermore, if file IS opened by the second client and the first client never responded, or responds after the timeout occurs, then you can end up with file corruption, as the first client finally flushes changes to disk, after the second client has read the now outdated data, and is using it. Regardless of the problems, the fact of the matter is that if Samba does not enable oplocks by default, just as Windows NT and 2000 servers do, then Samba servers yeild much lower performance for many server file operations performed by the typical Windows network client. You would have everyone screaming about how slow the network is, and Samba would come nowhere near the performance of Windows NT/2000 servers in benchmarks. I have been using shared file databases on Windows NT and Windows 2000 servers for years now (dBASE files). For all customer installs, we *MUST* disable oplocks on the NT/2000 servers in order to maintain database integrity. So this problem is not unique to Samba. Samba handles it much more gracefully than NT/2000 do! On NT/2000 servers, you have to edit a registry key that disables oplocks globally on the entire server. With Samba, I can disable them on a share or file wildcard pattern basis, using the 'veto oplock files' option in smb.conf. The user that compared Samba with/without oplocks to his Netware server's performance is not comparing apples to apples. Samba clients are using the Windows Networking client - and really can only be compared to a comparably equipped and configured Windows NT/2000 server. Netware servers require the use of a Netware client package. The Netware client has an entirely different implementation of locking mechanisms, caching algorithms, and the entire network protocol and file sharing model is different. As is the Netware server. I think most experts that have ever researched the topic will agree that for sheer file serving performance, nothing can beat Netware. Historically anyway. I've not seen any benchmarks that included Netware in a few years. Where Netware falls down is in 3rd party support (these days), and the ability to run general purpose applications on your server. Plus, the server and client licenses are a LOT more expensive than a Samba server solution. I'll hazard a bet that if one were to examine the Netware IPX/SPX protocol, it is nowhere nearly as convoluted and ad-hoc as the SMB protocol, which Microsoft hodge-podged together. You really have to step back and think about the amount of effort involved by the Samba Team in faithfully reverse engineering and reproducing all the intricate details of a protocol that is such a mess! Keep up the good work, 'Team Samba'! -- /----------------------------------------------- | Jim Morris | Email: [EMAIL PROTECTED] | | AIM: JFM2001 \----------------------------------------------- -- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
