Storing pipe opens in the share_mode db ?

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gerald (Jerry) Carter wrote:
> Jeremy Allison wrote:
> 
>>> I would prefer you not use the share mode db (the main
>>> open file db). The contention on this under load is
>>> *horrible*, plus it's the bottleneck for clustered
>>> Samba. I'd suggest another tdb, sorry.
>>>
>>> I'm afraid I think it's a horrible idea :-).
> 
> OK.  I'll respect that.  I don't agree, but I'll respect
> it.  Where do you propose?  I don't want to have
> create yet another tdb plus yet another set of fetch/store
> functions for something that is essentially a file open.

Volker says....

coffeedude: vl: any ideas where else I could store the pipe
  opens since wanon objects to locking.tdb ?
vl: A separate tdb.
coffeedude: vl: I hate that idea.  Oh well....Off I go
    for YATDB
vl: I don't like that either, as this essentially carries
  the same info as locking.tdb does. I'd much rather go
  with splitting up locking.tdb itself based on a
  inode-hashing scheme.
vl: This would help the contended case as well a lot.
vl: And I think the API is abstracted well enough now
  to make this really easy.

If Volker is ok with the cluster solution here then
would you be ok with using locking.tdb for pipe opens?





cheers, jerry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEiECXIR7qMdg1EfYRAuDFAKDCtL2yACVePxaPlHDjX5RZxAnDQACgugfR
1W/JSeiF9gaCQbu/nFxIC/M=
=qmy2
-----END PGP SIGNATURE-----