ctdb shortcut locking

[Volker Lendecke]

On Mon, Apr 16, 2007 at 05:23:54PM +1000, tridge at samba.org wrote:
> yes, but it seems to be fine in practice. You can simulate N children
> contending as fast as they can on one lock using the -n option to the
> test prog. I'm pretty happy with how it performs, even though it can
> loop more than once in the most heavily contended case.

For my taste this too much depends on the order in which the
SETLKW requests are replied. Under Linux it seems that new
requests are added to the end of the queue. But I don't feel
good to count on this for all Unixes. From the docs I've
looked at I did not see a guaranteed ordering on who wins
the SETLKW race.

How about the following thought: Why does the parent ctdbd
have to fcntl lock the tdb anyway? For the smbd<>ctdb link
smbd could chainlock the record, it would figure out we're
not dmaster and ask ctdbd to get us the data. For the
inter-node ctdb<>ctdb operations we could fork, the child
would do the necessary tdb operations, and send the record
contents back via the socket. This shifts the race above to
user-space: Which pipe do we handle first? Here we could
prioritize much easier than relying on the kernel to order
lock granting.

Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20070416/ecc871de/attachment.bin