tdb and file-per-hash-chain

[tridge at samba.org]

James,

 > I guess my view is that a shared write workload will always be bad in a
 > clustered environment irrespective of how clever the Samba locking is.
 > Shared reads is a different story - that is something that must be fast.

Shared write to user files might always be slow if the underlying
clustered filesystem is slow, but shared write to meta data (locking,
share modes etc) needs to be made fast, as that happens even when the
users are not doing shared writes to files.

A good example is the delete-on-close semantics that Jeremy has been
looking at recently. To get that right we need to check some shared
state about the delete on close flag on a file even when the user is
just doing a query_pathinfo call. That means that even if someone is
just looking at a directory view in explorer they will need to be
accessing shared state on open files on other nodes. It is a really
common situation for lots of people to be viewing a directory while
some people have one or more of the files open. It doesn't happen in
netbench, but it does happen in real world deployments (in fact its
the normal situation).

As we strive to bring Samba closer and closer to NTFS semantics for
this type of thing we will inevitably want more shared state like
this, not less. Any cluster solution needs to take this into account,
otherwise you will get the situation that users will scream that "all
I did was look at a directory listing and everything went slow on my
mega-buck cluster!".

 > The really nice aspect of doing this at the TDB level is that the
 > cluster takes care of any relocation, membership and failover tasks.
 > It's certainly not the most elegant solution, however.

yes, its a lovely abstraction, and very appealing in its simplicity. I
just think it will be too slow to be practical.

People want clustered Samba for different reasons. For those who want
it just for the convenience of accessing their existing cluster via
SMB then the speed won't matter. For those who are installing a
cluster because they think it will give them better performance then I
think they will be very disappointed with any system that tries to
cluster at the tdb level.

Cheers, Tridge