summaryrefslogtreecommitdiffstats
path: root/ctdb/lib/tdb/python/tdbdump.py
diff options
context:
space:
mode:
authorRusty Russell <rusty@rustcorp.com.au>2010-04-22 13:54:06 +0930
committerRusty Russell <rusty@rustcorp.com.au>2010-04-22 13:54:06 +0930
commit98b9b1defa9bed7c55a6828a47f1db58b02b9adf (patch)
tree05fe1551543d064b13f6f9abd47c63523504f214 /ctdb/lib/tdb/python/tdbdump.py
parenta617fb4ab1336cc81f6bf0bd57d0b1af6076110b (diff)
downloadsamba-98b9b1defa9bed7c55a6828a47f1db58b02b9adf.tar.gz
samba-98b9b1defa9bed7c55a6828a47f1db58b02b9adf.tar.xz
samba-98b9b1defa9bed7c55a6828a47f1db58b02b9adf.zip
tdb: handle processes dying during transaction commit.
tdb transactions were designed to be robust against the machine powering off, but interestingly were never designed to handle the case where an administrator kill -9's a process during commit. Because recovery is only done on tdb_open, processes with the tdb already mapped will simply use it despite it being corrupt and needing recovery. The solution to this is to check for recovery every time we grab a data lock: we could have gained the lock because a process just died. This has no measurable cost: here is the time for tdbtorture -s 0 -n 1 -l 10000: Before: 2.75 2.50 2.81 3.19 2.91 2.53 2.72 2.50 2.78 2.77 = Avg 2.75 After: 2.81 2.57 3.42 2.49 3.02 2.49 2.84 2.48 2.80 2.43 = Avg 2.74 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> (Imported from commit ec96ea690edbe3398d690b4a953d487ca1773f1c) (This used to be ctdb commit 4215c7025d2b29439c5acd19ce4e0fc4e67370b3)
Diffstat (limited to 'ctdb/lib/tdb/python/tdbdump.py')
0 files changed, 0 insertions, 0 deletions