W2K-Terminal Server vs Samba 2.0.7

[acherry at pobox.com]

Grotnes Per Kjetil PBE-SIT writes:
 > > You are missing the point that there is no "rdr.sys" on Win2K, but
 > > "mrxsmb.sys". I haven't seen MultipleUsersOnConnection used by MRxSmb or
 > > mentioned in MS KB for Win2K.

Heh, that would explain the absence of that part of the registry.

 > To keep the "thread" alive I just want to throw in a thought here.  Might it be that W2K does 
 > not have this problem?  That the OpSys can handle more than 2000 connections through a 
 > single process?  If so then the cause might be in the system that runs samba.  As in solaris 
 > the default file descriptor limit is 1024 pr. process.  
 >
 > Would you not get the same errors if the Unix system can not handle all those FD through the 
 > single connection like the Windows system?  

Yes, even if Win2K doesn't exhibit the same limits that 4.0 did, if
you hit a limit on the server side you'll still have problems.

We never actually ran into an open file limit with our WTS 4.0 system
and Samba.  The problem we ran into was with file locking.  Having
multiple users on one smbd process was particularly disastrous for
multiuser Access databases.  At least on Solaris, Samba uses fcntl()
record locking for byte-range locks.  The big problem is that fcntl()
locks are meant to prevent one process from modifying data that
another process has locked -- they aren't meant to be used within the
context of the *same* process.  MS Access uses byte-range locks on the
.LDB file to keep track of which users have what database records
locked.  This works fine with individual PCs, but not with multiple
Terminal Server users.  The second WTS user to open up the database
would blow away the first WTS user's locked entry in the LDB file (you
can actually sit and watch this by running "strings" and/or "lslk" on
the LDB file).  If you have only WTS users accessing the database,
you'll never get more than one entry in the LDB file (that of the most
recent user to open the database). This tends to result in database
corruption and other unpredictable behavior.

Switching the WTS clients to disallow multiple users per connection
gets around this problem, since you end up with separate smbd
processes for each user.

If Win2K doesn't allow turning this "feature" off, the only
alternatives I could see are to either rewrite Samba's locking
mechanisms to be entirely internal (using UID/PID or UID/client
pairs), or to have a single de-multiplexer process that routes data to
separate smbd processes.  Either solution would make the code more
complex and would be likely to slow things down.  And the first
approach still doesn't address the problem of limits to file
descriptors for UNIX processes, which may or may not be tunable
depending on the OS.

I imagine Windows Terminal Server systems are the first to really
bring this problem to light.  Other smaller-scale uses of SMB
multiplexing (i.e. ClearCase) are probably less likely to produce a
situation where several "users" from the same client are competing
for locked areas of a file.  But magnify this to 50, 100, or 1000+
users and add files with heavy contention (i.e. MS Access) and it's
a different ball of wax.  (Of course, given a choice, you really don't
want to use MS Access for more than, say, 3 users, but it happens
anyway. :S )

Yuck.

-Andrew Cherry