Adrian LEE wrote:
> we have a ever increasing use of this very
> large central fileserver and we've now reached the threshold
> we're this Solaris vs. Samba problem exposes itself enough to
> make for unhappy customers.
Ok, I have some info and a question about the
workaround.
The application is an ISAM-like one, using
fcntl locks on IBM, VMS and Unix. These
are taken on the whole file at open time
and used to ensure consistency in the index file.
With 50 files open and 2000 users, smbd slows to a crawl.
On IBM, 2300 users are handles easily. Without this
problem, the Sun will handle 6000 users.
Sun has this open as bug number 4700402, and is
discussing stuff that's currently way over my head...
In the meantime, we're trying building an smbd with
spinlocks. Jeremy has cautioned us that This May Be Bad (;-))
So, let me ask some spinlock question:
1) I know that if one process goes down holding a
spinlock, the lock will be non-removable. Will it be
removed if all smbds go down, and specifically if
they go down on a system crash, or are they persistent?
2) if they are persistent (they appear to be part of the tdb
data structure ???) can the system be brought down and then
recover/delete them?
3) will they be cleaned up if a client machine goes
down and the smbd discovers this via a keepalive?
If we can find a workaround with acceptable behavior,
I'll recommend isolating this set of databases on a
single samba, dedicated to that task and using spinlocks.
This is still a workaround, but the production system
is at risk both ways...
--dave
--
David Collier-Brown, | Always do right. This will gratify
Performance & Engineering | some people and astonish the rest.
Americas Customer Engineering, | -- Mark Twain
(905) 415-2849 | [EMAIL PROTECTED]
