1 #LyX 1.6.5 created this file. For more info see http://www.lyx.org/
6 \use_default_options true
11 \font_typewriter default
12 \font_default_family default
19 \paperfontsize default
27 \paperorientation portrait
30 \paragraph_separation indent
32 \quotes_language english
35 \paperpagestyle default
36 \tracking_changes true
45 TDB2: A Redesigning The Trivial DataBase
49 Rusty Russell, IBM Corporation
56 \begin_layout Abstract
57 The Trivial DataBase on-disk format is 32 bits; with usage cases heading
58 towards the 4G limit, that must change.
59 This required breakage provides an opportunity to revisit TDB's other design
60 decisions and reassess them.
67 \begin_layout Standard
68 The Trivial DataBase was originally written by Andrew Tridgell as a simple
69 key/data pair storage system with the same API as dbm, but allowing multiple
70 readers and writers while being small enough (< 1000 lines of C) to include
72 The simple design created in 1999 has proven surprisingly robust and performant
73 , used in Samba versions 3 and 4 as well as numerous other projects.
74 Its useful life was greatly increased by the (backwards-compatible!) addition
75 of transaction support in 2005.
78 \begin_layout Standard
79 The wider variety and greater demands of TDB-using code has lead to some
80 organic growth of the API, as well as some compromises on the implementation.
81 None of these, by themselves, are seen as show-stoppers, but the cumulative
82 effect is to a loss of elegance over the initial, simple TDB implementation.
83 Here is a table of the approximate number of lines of implementation code
84 and number of API functions at the end of each year:
87 \begin_layout Standard
89 <lyxtabular version="3" rows="12" columns="3">
91 <column alignment="center" valignment="top" width="0">
92 <column alignment="center" valignment="top" width="0">
93 <column alignment="center" valignment="top" width="0">
95 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
98 \begin_layout Plain Layout
104 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
107 \begin_layout Plain Layout
113 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" rightline="true" usebox="none">
116 \begin_layout Plain Layout
117 Lines of C Code Implementation
124 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
127 \begin_layout Plain Layout
133 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
136 \begin_layout Plain Layout
142 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
145 \begin_layout Plain Layout
153 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
156 \begin_layout Plain Layout
162 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
165 \begin_layout Plain Layout
171 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
174 \begin_layout Plain Layout
182 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
185 \begin_layout Plain Layout
191 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
194 \begin_layout Plain Layout
200 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
203 \begin_layout Plain Layout
211 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
214 \begin_layout Plain Layout
220 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
223 \begin_layout Plain Layout
229 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
232 \begin_layout Plain Layout
240 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
243 \begin_layout Plain Layout
249 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
252 \begin_layout Plain Layout
258 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
261 \begin_layout Plain Layout
269 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
272 \begin_layout Plain Layout
278 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
281 \begin_layout Plain Layout
287 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
290 \begin_layout Plain Layout
298 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
301 \begin_layout Plain Layout
307 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
310 \begin_layout Plain Layout
316 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
319 \begin_layout Plain Layout
327 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
330 \begin_layout Plain Layout
336 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
339 \begin_layout Plain Layout
345 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
348 \begin_layout Plain Layout
356 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
359 \begin_layout Plain Layout
365 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
368 \begin_layout Plain Layout
374 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
377 \begin_layout Plain Layout
385 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
388 \begin_layout Plain Layout
394 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
397 \begin_layout Plain Layout
403 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
406 \begin_layout Plain Layout
414 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
417 \begin_layout Plain Layout
423 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
426 \begin_layout Plain Layout
432 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" rightline="true" usebox="none">
435 \begin_layout Plain Layout
449 \begin_layout Standard
450 This review is an attempt to catalog and address all the known issues with
451 TDB and create solutions which address the problems without significantly
452 increasing complexity; all involved are far too aware of the dangers of
453 second system syndrome in rewriting a successful project like this.
456 \begin_layout Section
460 \begin_layout Subsection
461 tdb_open_ex Is Not Expandable
464 \begin_layout Standard
465 The tdb_open() call was expanded to tdb_open_ex(), which added an optional
466 hashing function and an optional logging function argument.
467 Additional arguments to open would require the introduction of a tdb_open_ex2
471 \begin_layout Subsubsection
475 \begin_layout Standard
476 tdb_open() will take a linked-list of attributes:
479 \begin_layout LyX-Code
483 \begin_layout LyX-Code
484 TDB_ATTRIBUTE_LOG = 0,
487 \begin_layout LyX-Code
488 TDB_ATTRIBUTE_HASH = 1
491 \begin_layout LyX-Code
495 \begin_layout LyX-Code
496 struct tdb_attribute_base {
499 \begin_layout LyX-Code
500 enum tdb_attribute attr;
503 \begin_layout LyX-Code
504 union tdb_attribute *next;
507 \begin_layout LyX-Code
511 \begin_layout LyX-Code
512 struct tdb_attribute_log {
515 \begin_layout LyX-Code
516 struct tdb_attribute_base base; /* .attr = TDB_ATTRIBUTE_LOG */
519 \begin_layout LyX-Code
523 \begin_layout LyX-Code
527 \begin_layout LyX-Code
531 \begin_layout LyX-Code
532 struct tdb_attribute_hash {
535 \begin_layout LyX-Code
536 struct tdb_attribute_base base; /* .attr = TDB_ATTRIBUTE_HASH */
539 \begin_layout LyX-Code
540 tdb_hash_func hash_fn;
543 \begin_layout LyX-Code
547 \begin_layout LyX-Code
551 \begin_layout LyX-Code
552 union tdb_attribute {
555 \begin_layout LyX-Code
556 struct tdb_attribute_base base;
559 \begin_layout LyX-Code
560 struct tdb_attribute_log log;
563 \begin_layout LyX-Code
564 struct tdb_attribute_hash hash;
567 \begin_layout LyX-Code
571 \begin_layout Standard
572 This allows future attributes to be added, even if this expands the size
576 \begin_layout Subsection
577 tdb_traverse Makes Impossible Guarantees
580 \begin_layout Standard
581 tdb_traverse (and tdb_firstkey/tdb_nextkey) predate transactions, and it
582 was thought that it was important to guarantee that all records which exist
583 at the start and end of the traversal would be included, and no record
584 would be included twice.
587 \begin_layout Standard
588 This adds complexity (see
589 \begin_inset CommandInset ref
591 reference "Reliable-Traversal-Adds"
595 ) and does not work anyway for records which are altered (in particular,
596 those which are expanded may be effectively deleted and re-added behind
600 \begin_layout Subsubsection
601 \begin_inset CommandInset label
603 name "traverse-Proposed-Solution"
610 \begin_layout Standard
611 Abandon the guarantee.
612 You will see every record if no changes occur during your traversal, otherwise
613 you will see some subset.
614 You can prevent changes by using a transaction or the locking API.
617 \begin_layout Subsection
618 Nesting of Transactions Is Fraught
621 \begin_layout Standard
622 TDB has alternated between allowing nested transactions and not allowing
624 Various paths in the Samba codebase assume that transactions will nest,
625 and in a sense they can: the operation is only committed to disk when the
626 outer transaction is committed.
627 There are two problems, however:
630 \begin_layout Enumerate
631 Canceling the inner transaction will cause the outer transaction commit
632 to fail, and will not undo any operations since the inner transaction began.
633 This problem is soluble with some additional internal code.
636 \begin_layout Enumerate
637 An inner transaction commit can be cancelled by the outer transaction.
638 This is desirable in the way which Samba's database initialization code
639 uses transactions, but could be a surprise to any users expecting a successful
640 transaction commit to expose changes to others.
643 \begin_layout Standard
644 The current solution is to specify the behavior at tdb_open(), with the
645 default currently that nested transactions are allowed.
646 This flag can also be changed at runtime.
649 \begin_layout Subsubsection
653 \begin_layout Standard
654 Given the usage patterns, it seems that the
655 \begin_inset Quotes eld
659 \begin_inset Quotes erd
662 behavior of disallowing nested transactions should become the default.
663 Additionally, it seems the outer transaction is the only code which knows
664 whether inner transactions should be allowed, so a flag to indicate this
665 could be added to tdb_transaction_start.
666 However, this behavior can be simulated with a wrapper which uses tdb_add_flags
667 () and tdb_remove_flags(), so the API should not be expanded for this relatively
671 \begin_layout Subsection
672 Incorrect Hash Function is Not Detected
675 \begin_layout Standard
676 tdb_open_ex() allows the calling code to specify a different hash function
677 to use, but does not check that all other processes accessing this tdb
678 are using the same hash function.
679 The result is that records are missing from tdb_fetch().
682 \begin_layout Subsubsection
686 \begin_layout Standard
687 The header should contain an example hash result (eg.
688 the hash of 0xdeadbeef), and tdb_open_ex() should check that the given
689 hash function produces the same answer, or fail the tdb_open call.
692 \begin_layout Subsection
693 tdb_set_max_dead/TDB_VOLATILE Expose Implementation
696 \begin_layout Standard
697 In response to scalability issues with the free list (
698 \begin_inset CommandInset ref
700 reference "TDB-Freelist-Is"
704 ) two API workarounds have been incorporated in TDB: tdb_set_max_dead()
705 and the TDB_VOLATILE flag to tdb_open.
706 The latter actually calls the former with an argument of
707 \begin_inset Quotes eld
711 \begin_inset Quotes erd
717 \begin_layout Standard
718 This code allows deleted records to accumulate without putting them in the
720 On delete we iterate through each chain and free them in a batch if there
721 are more than max_dead entries.
722 These are never otherwise recycled except as a side-effect of a tdb_repack.
725 \begin_layout Subsubsection
729 \begin_layout Standard
730 With the scalability problems of the freelist solved, this API can be removed.
731 The TDB_VOLATILE flag may still be useful as a hint that store and delete
732 of records will be at least as common as fetch in order to allow some internal
733 tuning, but initially will become a no-op.
736 \begin_layout Subsection
737 \begin_inset CommandInset label
739 name "TDB-Files-Cannot"
743 TDB Files Cannot Be Opened Multiple Times In The Same Process
746 \begin_layout Standard
747 No process can open the same TDB twice; we check and disallow it.
748 This is an unfortunate side-effect of fcntl locks, which operate on a per-file
749 rather than per-file-descriptor basis, and do not nest.
750 Thus, closing any file descriptor on a file clears all the locks obtained
751 by this process, even if they were placed using a different file descriptor!
754 \begin_layout Standard
755 Note that even if this were solved, deadlock could occur if operations were
756 nested: this is a more manageable programming error in most cases.
759 \begin_layout Subsubsection
763 \begin_layout Standard
764 We could lobby POSIX to fix the perverse rules, or at least lobby Linux
765 to violate them so that the most common implementation does not have this
767 This would be a generally good idea for other fcntl lock users.
770 \begin_layout Standard
771 Samba uses a wrapper which hands out the same tdb_context to multiple callers
772 if this happens, and does simple reference counting.
773 We should do this inside the tdb library, which already emulates lock nesting
774 internally; it would need to recognize when deadlock occurs within a single
776 This would create a new failure mode for tdb operations (while we currently
777 handle locking failures, they are impossible in normal use and a process
778 encountering them can do little but give up).
781 \begin_layout Standard
782 I do not see benefit in an additional tdb_open flag to indicate whether
783 re-opening is allowed, as though there may be some benefit to adding a
784 call to detect when a tdb_context is shared, to allow other to create such
788 \begin_layout Subsection
789 TDB API Is Not POSIX Thread-safe
792 \begin_layout Standard
793 The TDB API uses an error code which can be queried after an operation to
794 determine what went wrong.
795 This programming model does not work with threads, unless specific additional
796 guarantees are given by the implementation.
797 In addition, even otherwise-independent threads cannot open the same TDB
799 \begin_inset CommandInset ref
801 reference "TDB-Files-Cannot"
808 \begin_layout Subsubsection
812 \begin_layout Standard
813 Reachitecting the API to include a tdb_errcode pointer would be a great
814 deal of churn; we are better to guarantee that the tdb_errcode is per-thread
815 so the current programming model can be maintained.
818 \begin_layout Standard
819 This requires dynamic per-thread allocations, which is awkward with POSIX
820 threads (pthread_key_create space is limited and we cannot simply allocate
821 a key for every TDB).
824 \begin_layout Standard
825 Internal locking is required to make sure that fcntl locks do not overlap
826 between threads, and also that the global list of tdbs is maintained.
829 \begin_layout Standard
830 The aim is that building tdb with -DTDB_PTHREAD will result in a pthread-safe
831 version of the library, and otherwise no overhead will exist.
834 \begin_layout Subsection
835 *_nonblock Functions And *_mark Functions Expose Implementation
838 \begin_layout Standard
843 \begin_layout Plain Layout
844 Clustered TDB, see http://ctdb.samba.org
849 wishes to operate on TDB in a non-blocking manner.
850 This is currently done as follows:
853 \begin_layout Enumerate
854 Call the _nonblock variant of an API function (eg.
855 tdb_lockall_nonblock).
859 \begin_layout Enumerate
860 Fork a child process, and wait for it to call the normal variant (eg.
864 \begin_layout Enumerate
865 If the child succeeds, call the _mark variant to indicate we already have
870 \begin_layout Enumerate
871 Upon completion, tell the child to release the locks (eg.
875 \begin_layout Enumerate
876 Indicate to tdb that it should consider the locks removed (eg.
880 \begin_layout Standard
881 There are several issues with this approach.
882 Firstly, adding two new variants of each function clutters the API for
883 an obscure use, and so not all functions have three variants.
884 Secondly, it assumes that all paths of the functions ask for the same locks,
885 otherwise the parent process will have to get a lock which the child doesn't
886 have under some circumstances.
887 I don't believe this is currently the case, but it constrains the implementatio
892 \begin_layout Subsubsection
893 \begin_inset CommandInset label
895 name "Proposed-Solution-locking-hook"
902 \begin_layout Standard
903 Implement a hook for locking methods, so that the caller can control the
904 calls to create and remove fcntl locks.
905 In this scenario, ctdbd would operate as follows:
908 \begin_layout Enumerate
909 Call the normal API function, eg tdb_lockall().
912 \begin_layout Enumerate
913 When the lock callback comes in, check if the child has the lock.
914 Initially, this is always false.
916 Otherwise, try to obtain it in non-blocking mode.
917 If that fails, return EWOULDBLOCK.
920 \begin_layout Enumerate
921 Release locks in the unlock callback as normal.
924 \begin_layout Enumerate
925 If tdb_lockall() fails, see if we recorded a lock failure; if so, call the
926 child to repeat the operation.
929 \begin_layout Enumerate
930 The child records what locks it obtains, and returns that information to
934 \begin_layout Enumerate
935 When the child has succeeded, goto 1.
938 \begin_layout Standard
939 This is flexible enough to handle any potential locking scenario, even when
940 lock requirements change.
941 It can be optimized so that the parent does not release locks, just tells
942 the child which locks it doesn't need to obtain.
945 \begin_layout Standard
946 It also keeps the complexity out of the API, and in ctdbd where it is needed.
949 \begin_layout Subsection
950 tdb_chainlock Functions Expose Implementation
953 \begin_layout Standard
954 tdb_chainlock locks some number of records, including the record indicated
956 This gave atomicity guarantees; no-one can start a transaction, alter,
957 read or delete that key while the lock is held.
960 \begin_layout Standard
961 It also makes the same guarantee for any other key in the chain, which is
962 an internal implementation detail and potentially a cause for deadlock.
965 \begin_layout Subsubsection
969 \begin_layout Standard
971 It would be nice to have an explicit single entry lock which effected no
973 Unfortunately, this won't work for an entry which doesn't exist.
974 Thus while chainlock may be implemented more efficiently for the existing
975 case, it will still have overlap issues with the non-existing case.
976 So it is best to keep the current (lack of) guarantee about which records
977 will be effected to avoid constraining our implementation.
980 \begin_layout Subsection
981 Signal Handling is Not Race-Free
984 \begin_layout Standard
985 The tdb_setalarm_sigptr() call allows the caller's signal handler to indicate
986 that the tdb locking code should return with a failure, rather than trying
987 again when a signal is received (and errno == EAGAIN).
988 This is usually used to implement timeouts.
991 \begin_layout Standard
992 Unfortunately, this does not work in the case where the signal is received
993 before the tdb code enters the fcntl() call to place the lock: the code
994 will sleep within the fcntl() code, unaware that the signal wants it to
996 In the case of long timeouts, this does not happen in practice.
999 \begin_layout Subsubsection
1003 \begin_layout Standard
1004 The locking hooks proposed in
1005 \begin_inset CommandInset ref
1007 reference "Proposed-Solution-locking-hook"
1011 would allow the user to decide on whether to fail the lock acquisition
1013 This allows the caller to choose their own compromise: they could narrow
1014 the race by checking immediately before the fcntl call.
1018 \begin_layout Plain Layout
1019 It may be possible to make this race-free in some implementations by having
1020 the signal handler alter the struct flock to make it invalid.
1021 This will cause the fcntl() lock call to fail with EINVAL if the signal
1022 occurs before the kernel is entered, otherwise EAGAIN.
1030 \begin_layout Subsection
1031 The API Uses Gratuitous Typedefs, Capitals
1034 \begin_layout Standard
1035 typedefs are useful for providing source compatibility when types can differ
1036 across implementations, or arguably in the case of function pointer definitions
1037 which are hard for humans to parse.
1038 Otherwise it is simply obfuscation and pollutes the namespace.
1041 \begin_layout Standard
1042 Capitalization is usually reserved for compile-time constants and macros.
1045 \begin_layout Description
1046 TDB_CONTEXT There is no reason to use this over 'struct tdb_context'; the
1047 definition isn't visible to the API user anyway.
1050 \begin_layout Description
1051 TDB_DATA There is no reason to use this over struct TDB_DATA; the struct
1052 needs to be understood by the API user.
1055 \begin_layout Description
1057 \begin_inset space ~
1060 TDB_DATA This would normally be called 'struct tdb_data'.
1063 \begin_layout Description
1065 \begin_inset space ~
1068 TDB_ERROR Similarly, this would normally be enum tdb_error.
1071 \begin_layout Subsubsection
1075 \begin_layout Standard
1077 Introducing lower case variants would please pedants like myself, but if
1078 it were done the existing ones should be kept.
1079 There is little point forcing a purely cosmetic change upon tdb users.
1082 \begin_layout Subsection
1083 \begin_inset CommandInset label
1085 name "tdb_log_func-Doesnt-Take"
1089 tdb_log_func Doesn't Take The Private Pointer
1092 \begin_layout Standard
1093 For API compatibility reasons, the logging function needs to call tdb_get_loggin
1094 g_private() to retrieve the pointer registered by the tdb_open_ex for logging.
1097 \begin_layout Subsubsection
1101 \begin_layout Standard
1102 It should simply take an extra argument, since we are prepared to break
1106 \begin_layout Subsection
1107 Various Callback Functions Are Not Typesafe
1110 \begin_layout Standard
1111 The callback functions in tdb_set_logging_function (after
1112 \begin_inset CommandInset ref
1114 reference "tdb_log_func-Doesnt-Take"
1118 is resolved), tdb_parse_record, tdb_traverse, tdb_traverse_read and tdb_check
1119 all take void * and must internally convert it to the argument type they
1123 \begin_layout Standard
1124 If this type changes, the compiler will not produce warnings on the callers,
1125 since it only sees void *.
1128 \begin_layout Subsubsection
1132 \begin_layout Standard
1133 With careful use of macros, we can create callback functions which give
1134 a warning when used on gcc and the types of the callback and its private
1136 Unsupported compilers will not give a warning, which is no worse than now.
1137 In addition, the callbacks become clearer, as they need not use void *
1138 for their parameter.
1141 \begin_layout Standard
1142 See CCAN's typesafe_cb module at http://ccan.ozlabs.org/info/typesafe_cb.html
1145 \begin_layout Subsection
1146 TDB_CLEAR_IF_FIRST Must Be Specified On All Opens, tdb_reopen_all Problematic
1149 \begin_layout Standard
1150 The TDB_CLEAR_IF_FIRST flag to tdb_open indicates that the TDB file should
1151 be cleared if the caller discovers it is the only process with the TDB
1153 However, if any caller does not specify TDB_CLEAR_IF_FIRST it will not
1154 be detected, so will have the TDB erased underneath them (usually resulting
1158 \begin_layout Standard
1159 There is a similar issue on fork(); if the parent exits (or otherwise closes
1160 the tdb) before the child calls tdb_reopen_all() to establish the lock
1161 used to indicate the TDB is opened by someone, a TDB_CLEAR_IF_FIRST opener
1162 at that moment will believe it alone has opened the TDB and will erase
1166 \begin_layout Subsubsection
1170 \begin_layout Standard
1171 Remove TDB_CLEAR_IF_FIRST.
1172 Other workarounds are possible, but see
1173 \begin_inset CommandInset ref
1175 reference "TDB_CLEAR_IF_FIRST-Imposes-Performance"
1182 \begin_layout Section
1183 Performance And Scalability Issues
1186 \begin_layout Subsection
1187 \begin_inset CommandInset label
1189 name "TDB_CLEAR_IF_FIRST-Imposes-Performance"
1193 TDB_CLEAR_IF_FIRST Imposes Performance Penalty
1196 \begin_layout Standard
1197 When TDB_CLEAR_IF_FIRST is specified, a 1-byte read lock is placed at offset
1200 While these locks never conflict in normal tdb usage, they do add substantial
1201 overhead for most fcntl lock implementations when the kernel scans to detect
1202 if a lock conflict exists.
1203 This is often a single linked list, making the time to acquire and release
1204 a fcntl lock O(N) where N is the number of processes with the TDB open,
1205 not the number actually doing work.
1208 \begin_layout Standard
1209 In a Samba server it is common to have huge numbers of clients sitting idle,
1210 and thus they have weaned themselves off the TDB_CLEAR_IF_FIRST flag.
1214 \begin_layout Plain Layout
1215 There is a flag to tdb_reopen_all() which is used for this optimization:
1216 if the parent process will outlive the child, the child does not need the
1218 This is a workaround for this very performance issue.
1226 \begin_layout Subsubsection
1230 \begin_layout Standard
1232 It was a neat idea, but even trivial servers tend to know when they are
1233 initializing for the first time and can simply unlink the old tdb at that
1237 \begin_layout Subsection
1238 TDB Files Have a 4G Limit
1241 \begin_layout Standard
1242 This seems to be becoming an issue (so much for
1243 \begin_inset Quotes eld
1247 \begin_inset Quotes erd
1250 !), particularly for ldb.
1253 \begin_layout Subsubsection
1257 \begin_layout Standard
1258 A new, incompatible TDB format which uses 64 bit offsets internally rather
1260 For simplicity of endian conversion (which TDB does on the fly if required),
1261 all values will be 64 bit on disk.
1262 In practice, some upper bits may be used for other purposes, but at least
1263 56 bits will be available for file offsets.
1266 \begin_layout Standard
1267 tdb_open() will automatically detect the old version, and even create them
1268 if TDB_VERSION6 is specified to tdb_open.
1271 \begin_layout Standard
1272 32 bit processes will still be able to access TDBs larger than 4G (assuming
1273 that their off_t allows them to seek to 64 bits), they will gracefully
1274 fall back as they fail to mmap.
1275 This can happen already with large TDBs.
1278 \begin_layout Standard
1279 Old versions of tdb will fail to open the new TDB files (since 28 August
1280 2009, commit 398d0c29290: prior to that any unrecognized file format would
1281 be erased and initialized as a fresh tdb!)
1284 \begin_layout Subsection
1285 TDB Records Have a 4G Limit
1288 \begin_layout Standard
1289 This has not been a reported problem, and the API uses size_t which can
1290 be 64 bit on 64 bit platforms.
1291 However, other limits may have made such an issue moot.
1294 \begin_layout Subsubsection
1298 \begin_layout Standard
1299 Record sizes will be 64 bit, with an error returned on 32 bit platforms
1300 which try to access such records (the current implementation would return
1301 TDB_ERR_OOM in a similar case).
1302 It seems unlikely that 32 bit keys will be a limitation, so the implementation
1303 may not support this (see
1304 \begin_inset CommandInset ref
1306 reference "sub:Records-Incur-A"
1313 \begin_layout Subsection
1314 Hash Size Is Determined At TDB Creation Time
1317 \begin_layout Standard
1318 TDB contains a number of hash chains in the header; the number is specified
1319 at creation time, and defaults to 131.
1320 This is such a bottleneck on large databases (as each hash chain gets quite
1321 long), that LDB uses 10,000 for this hash.
1322 In general it is impossible to know what the 'right' answer is at database
1326 \begin_layout Subsubsection
1330 \begin_layout Standard
1331 After comprehensive performance testing on various scalable hash variants
1335 \begin_layout Plain Layout
1336 http://rusty.ozlabs.org/?p=89 and http://rusty.ozlabs.org/?p=94 This was annoying
1337 because I was previously convinced that an expanding tree of hashes would
1338 be very close to optimal.
1343 , it became clear that it is hard to beat a straight linear hash table which
1344 doubles in size when it reaches saturation.
1345 There are three details which become important:
1348 \begin_layout Enumerate
1349 On encountering a full bucket, we use the next bucket.
1352 \begin_layout Enumerate
1353 Extra hash bits are stored with the offset, to reduce comparisons.
1356 \begin_layout Enumerate
1357 A marker entry is used on deleting an entry.
1360 \begin_layout Standard
1361 The doubling of the table must be done under a transaction; we will not
1362 reduce it on deletion, so it will be an unusual case.
1363 It will either be placed at the head (other entries will be moved out the
1364 way so we can expand).
1365 We could have a pointer in the header to the current hashtable location,
1366 but that pointer would have to be read frequently to check for hashtable
1370 \begin_layout Standard
1371 The locking for this is slightly more complex than the chained case; we
1372 currently have one lock per bucket, and that means we would need to expand
1373 the lock if we overflow to the next bucket.
1374 The frequency of such collisions will effect our locking heuristics: we
1375 can always lock more buckets than we need.
1378 \begin_layout Standard
1379 One possible optimization is to only re-check the hash size on an insert
1383 \begin_layout Subsection
1384 \begin_inset CommandInset label
1386 name "TDB-Freelist-Is"
1390 TDB Freelist Is Highly Contended
1393 \begin_layout Standard
1394 TDB uses a single linked list for the free list.
1395 Allocation occurs as follows, using heuristics which have evolved over
1399 \begin_layout Enumerate
1400 Get the free list lock for this whole operation.
1403 \begin_layout Enumerate
1404 Multiply length by 1.25, so we always over-allocate by 25%.
1407 \begin_layout Enumerate
1408 Set the slack multiplier to 1.
1411 \begin_layout Enumerate
1412 Examine the current freelist entry: if it is > length but < the current
1413 best case, remember it as the best case.
1416 \begin_layout Enumerate
1417 Multiply the slack multiplier by 1.05.
1420 \begin_layout Enumerate
1421 If our best fit so far is less than length * slack multiplier, return it.
1422 The slack will be turned into a new free record if it's large enough.
1425 \begin_layout Enumerate
1426 Otherwise, go onto the next freelist entry.
1429 \begin_layout Standard
1430 Deleting a record occurs as follows:
1433 \begin_layout Enumerate
1434 Lock the hash chain for this whole operation.
1437 \begin_layout Enumerate
1438 Walk the chain to find the record, keeping the prev pointer offset.
1441 \begin_layout Enumerate
1442 If max_dead is non-zero:
1446 \begin_layout Enumerate
1447 Walk the hash chain again and count the dead records.
1450 \begin_layout Enumerate
1451 If it's more than max_dead, bulk free all the dead ones (similar to steps
1452 4 and below, but the lock is only obtained once).
1455 \begin_layout Enumerate
1456 Simply mark this record as dead and return.
1461 \begin_layout Enumerate
1462 Get the free list lock for the remainder of this operation.
1465 \begin_layout Enumerate
1466 \begin_inset CommandInset label
1468 name "right-merging"
1472 Examine the following block to see if it is free; if so, enlarge the current
1473 block and remove that block from the free list.
1474 This was disabled, as removal from the free list was O(entries-in-free-list).
1477 \begin_layout Enumerate
1478 Examine the preceeding block to see if it is free: for this reason, each
1479 block has a 32-bit tailer which indicates its length.
1480 If it is free, expand it to cover our new block and return.
1483 \begin_layout Enumerate
1484 Otherwise, prepend ourselves to the free list.
1487 \begin_layout Standard
1488 Disabling right-merging (step
1489 \begin_inset CommandInset ref
1491 reference "right-merging"
1495 ) causes fragmentation; the other heuristics proved insufficient to address
1496 this, so the final answer to this was that when we expand the TDB file
1497 inside a transaction commit, we repack the entire tdb.
1500 \begin_layout Standard
1501 The single list lock limits our allocation rate; due to the other issues
1502 this is not currently seen as a bottleneck.
1505 \begin_layout Subsubsection
1509 \begin_layout Standard
1510 The first step is to remove all the current heuristics, as they obviously
1511 interact, then examine them once the lock contention is addressed.
1514 \begin_layout Standard
1515 The free list must be split to reduce contention.
1516 Assuming perfect free merging, we can at most have 1 free list entry for
1518 This implies that the number of free lists is related to the size of the
1519 hash table, but as it is rare to walk a large number of free list entries
1520 we can use far fewer, say 1/32 of the number of hash buckets.
1523 \begin_layout Standard
1524 There are various benefits in using per-size free lists (see
1525 \begin_inset CommandInset ref
1527 reference "sub:TDB-Becomes-Fragmented"
1531 ) but it's not clear this would reduce contention in the common case where
1532 all processes are allocating/freeing the same size.
1533 Thus we almost certainly need to divide in other ways: the most obvious
1534 is to divide the file into zones, and using a free list (or set of free
1536 This approximates address ordering.
1539 \begin_layout Standard
1540 Note that this means we need to split the free lists when we expand the
1541 file; this is probably acceptable when we double the hash table size, since
1542 that is such an expensive operation already.
1543 In the case of increasing the file size, there is an optimization we can
1544 use: if we use M in the formula above as the file size rounded up to the
1545 next power of 2, we only need reshuffle free lists when the file size crosses
1546 a power of 2 boundary,
1550 reshuffling the free lists is trivial: we simply merge every consecutive
1554 \begin_layout Standard
1555 The basic algorithm is as follows.
1559 \begin_layout Enumerate
1560 Identify the correct zone.
1563 \begin_layout Enumerate
1564 Lock the corresponding list.
1567 \begin_layout Enumerate
1568 Re-check the zone (we didn't have a lock, sizes could have changed): relock
1572 \begin_layout Enumerate
1573 Place the freed entry in the list for that zone.
1576 \begin_layout Standard
1577 Allocation is a little more complicated, as we perform delayed coalescing
1581 \begin_layout Enumerate
1582 Pick a zone either the zone we last freed into, or based on a
1583 \begin_inset Quotes eld
1587 \begin_inset Quotes erd
1593 \begin_layout Enumerate
1594 Lock the corresponding list.
1597 \begin_layout Enumerate
1598 Re-check the zone: relock if necessary.
1601 \begin_layout Enumerate
1602 If the top entry is -large enough, remove it from the list and return it.
1605 \begin_layout Enumerate
1606 Otherwise, coalesce entries in the list.If there was no entry large enough,
1607 unlock the list and try the next zone.
1610 \begin_layout Enumerate
1611 If no zone satisfies, expand the file.
1614 \begin_layout Standard
1615 This optimizes rapid insert/delete of free list entries by not coalescing
1617 First-fit address ordering ordering seems to be fairly good for keeping
1618 fragmentation low (see
1619 \begin_inset CommandInset ref
1621 reference "sub:TDB-Becomes-Fragmented"
1626 Note that address ordering does not need a tailer to coalesce, though if
1627 we needed one we could have one cheaply: see
1628 \begin_inset CommandInset ref
1630 reference "sub:Records-Incur-A"
1638 \begin_layout Standard
1639 I anticipate that the number of entries in each free zone would be small,
1640 but it might be worth using one free entry to hold pointers to the others
1641 for cache efficiency.
1644 \begin_layout Subsection
1645 \begin_inset CommandInset label
1647 name "sub:TDB-Becomes-Fragmented"
1651 TDB Becomes Fragmented
1654 \begin_layout Standard
1655 Much of this is a result of allocation strategy
1659 \begin_layout Plain Layout
1660 The Memory Fragmentation Problem: Solved? Johnstone & Wilson 1995 ftp://ftp.cs.ute
1661 xas.edu/pub/garbage/malloc/ismm98.ps
1666 and deliberate hobbling of coalescing; internal fragmentation (aka overallocati
1667 on) is deliberately set at 25%, and external fragmentation is only cured
1668 by the decision to repack the entire db when a transaction commit needs
1669 to enlarge the file.
1672 \begin_layout Subsubsection
1676 \begin_layout Standard
1677 The 25% overhead on allocation works in practice for ldb because indexes
1678 tend to expand by one record at a time.
1679 This internal fragmentation can be resolved by having an
1680 \begin_inset Quotes eld
1684 \begin_inset Quotes erd
1687 bit in the header to note entries that have previously expanded, and allocating
1688 more space for them.
1691 \begin_layout Standard
1692 There are is a spectrum of possible solutions for external fragmentation:
1693 one is to use a fragmentation-avoiding allocation strategy such as best-fit
1694 address-order allocator.
1695 The other end of the spectrum would be to use a bump allocator (very fast
1696 and simple) and simply repack the file when we reach the end.
1699 \begin_layout Standard
1700 There are three problems with efficient fragmentation-avoiding allocators:
1701 they are non-trivial, they tend to use a single free list for each size,
1702 and there's no evidence that tdb allocation patterns will match those recorded
1703 for general allocators (though it seems likely).
1706 \begin_layout Standard
1707 Thus we don't spend too much effort on external fragmentation; we will be
1708 no worse than the current code if we need to repack on occasion.
1709 More effort is spent on reducing freelist contention, and reducing overhead.
1712 \begin_layout Subsection
1713 \begin_inset CommandInset label
1715 name "sub:Records-Incur-A"
1719 Records Incur A 28-Byte Overhead
1722 \begin_layout Standard
1723 Each TDB record has a header as follows:
1726 \begin_layout LyX-Code
1730 \begin_layout LyX-Code
1731 tdb_off_t next; /* offset of the next record in the list */
1734 \begin_layout LyX-Code
1735 tdb_len_t rec_len; /* total byte length of record */
1738 \begin_layout LyX-Code
1739 tdb_len_t key_len; /* byte length of key */
1742 \begin_layout LyX-Code
1743 tdb_len_t data_len; /* byte length of data */
1746 \begin_layout LyX-Code
1747 uint32_t full_hash; /* the full 32 bit hash of the key */
1750 \begin_layout LyX-Code
1751 uint32_t magic; /* try to catch errors */
1754 \begin_layout LyX-Code
1755 /* the following union is implied:
1758 \begin_layout LyX-Code
1762 \begin_layout LyX-Code
1763 char record[rec_len];
1766 \begin_layout LyX-Code
1770 \begin_layout LyX-Code
1774 \begin_layout LyX-Code
1775 char data[data_len];
1778 \begin_layout LyX-Code
1782 \begin_layout LyX-Code
1783 uint32_t totalsize; (tailer)
1786 \begin_layout LyX-Code
1790 \begin_layout LyX-Code
1794 \begin_layout LyX-Code
1798 \begin_layout Standard
1799 Naively, this would double to a 56-byte overhead on a 64 bit implementation.
1802 \begin_layout Subsubsection
1806 \begin_layout Standard
1807 We can use various techniques to reduce this for an allocated block:
1810 \begin_layout Enumerate
1811 The 'next' pointer is not required, as we are using a flat hash table.
1814 \begin_layout Enumerate
1815 'rec_len' can instead be expressed as an addition to key_len and data_len
1816 (it accounts for wasted or overallocated length in the record).
1817 Since the record length is always a multiple of 8, we can conveniently
1818 fit it in 32 bits (representing up to 35 bits).
1821 \begin_layout Enumerate
1822 'key_len' and 'data_len' can be reduced.
1823 I'm unwilling to restrict 'data_len' to 32 bits, but instead we can combine
1824 the two into one 64-bit field and using a 5 bit value which indicates at
1825 what bit to divide the two.
1826 Keys are unlikely to scale as fast as data, so I'm assuming a maximum key
1830 \begin_layout Enumerate
1831 'full_hash' is used to avoid a memcmp on the
1832 \begin_inset Quotes eld
1836 \begin_inset Quotes erd
1839 case, but this is diminishing returns after a handful of bits (at 10 bits,
1840 it reduces 99.9% of false memcmp).
1841 As an aside, as the lower bits are already incorporated in the hash table
1842 resolution, the upper bits should be used here.
1845 \begin_layout Enumerate
1846 'magic' does not need to be enlarged: it currently reflects one of 5 values
1847 (used, free, dead, recovery, and unused_recovery).
1848 It is useful for quick sanity checking however, and should not be eliminated.
1851 \begin_layout Enumerate
1852 'tailer' is only used to coalesce free blocks (so a block to the right can
1853 find the header to check if this block is free).
1854 This can be replaced by a single 'free' bit in the header of the following
1855 block (and the tailer only exists in free blocks).
1859 \begin_layout Plain Layout
1860 This technique from Thomas Standish.
1861 Data Structure Techniques.
1862 Addison-Wesley, Reading, Massachusetts, 1980.
1867 The current proposed coalescing algorithm doesn't need this, however.
1870 \begin_layout Standard
1871 This produces a 16 byte used header like this:
1874 \begin_layout LyX-Code
1875 struct tdb_used_record {
1878 \begin_layout LyX-Code
1879 uint32_t magic : 16,
1882 \begin_layout LyX-Code
1886 \begin_layout LyX-Code
1890 \begin_layout LyX-Code
1894 \begin_layout LyX-Code
1895 uint32_t extra_octets;
1898 \begin_layout LyX-Code
1899 uint64_t key_and_data_len;
1902 \begin_layout LyX-Code
1906 \begin_layout Standard
1907 And a free record like this:
1910 \begin_layout LyX-Code
1911 struct tdb_free_record {
1914 \begin_layout LyX-Code
1915 uint32_t free_magic;
1918 \begin_layout LyX-Code
1919 uint64_t total_length;
1922 \begin_layout LyX-Code
1926 \begin_layout LyX-Code
1930 \begin_layout LyX-Code
1934 \begin_layout LyX-Code
1938 \begin_layout Subsection
1939 Transaction Commit Requires 4 fdatasync
1942 \begin_layout Standard
1943 The current transaction algorithm is:
1946 \begin_layout Enumerate
1947 write_recovery_data();
1950 \begin_layout Enumerate
1954 \begin_layout Enumerate
1955 write_recovery_header();
1958 \begin_layout Enumerate
1962 \begin_layout Enumerate
1963 overwrite_with_new_data();
1966 \begin_layout Enumerate
1970 \begin_layout Enumerate
1971 remove_recovery_header();
1974 \begin_layout Enumerate
1978 \begin_layout Standard
1979 On current ext3, each sync flushes all data to disk, so the next 3 syncs
1980 are relatively expensive.
1981 But this could become a performance bottleneck on other filesystems such
1985 \begin_layout Subsubsection
1989 \begin_layout Standard
1990 Neil Brown points out that this is overzealous, and only one sync is needed:
1993 \begin_layout Enumerate
1994 Bundle the recovery data, a transaction counter and a strong checksum of
1998 \begin_layout Enumerate
1999 Strong checksum that whole bundle.
2002 \begin_layout Enumerate
2003 Store the bundle in the database.
2006 \begin_layout Enumerate
2007 Overwrite the oldest of the two recovery pointers in the header (identified
2008 using the transaction counter) with the offset of this bundle.
2011 \begin_layout Enumerate
2015 \begin_layout Enumerate
2016 Write the new data to the file.
2019 \begin_layout Standard
2020 Checking for recovery means identifying the latest bundle with a valid checksum
2021 and using the new data checksum to ensure that it has been applied.
2022 This is more expensive than the current check, but need only be done at
2024 For running databases, a separate header field can be used to indicate
2025 a transaction in progress; we need only check for recovery if this is set.
2028 \begin_layout Subsection
2029 \begin_inset CommandInset label
2031 name "sub:TDB-Does-Not"
2035 TDB Does Not Have Snapshot Support
2038 \begin_layout Subsubsection
2042 \begin_layout Standard
2044 At some point you say
2045 \begin_inset Quotes eld
2049 \begin_inset Quotes erd
2055 \begin_layout Standard
2056 But as a thought experiment, if we implemented transactions to only overwrite
2057 free entries (this is tricky: there must not be a header in each entry
2058 which indicates whether it is free, but use of presence in metadata elsewhere),
2059 and a pointer to the hash table, we could create an entirely new commit
2060 without destroying existing data.
2061 Then it would be easy to implement snapshots in a similar way.
2064 \begin_layout Standard
2065 This would not allow arbitrary changes to the database, such as tdb_repack
2066 does, and would require more space (since we have to preserve the current
2067 and future entries at once).
2068 If we used hash trees rather than one big hash table, we might only have
2069 to rewrite some sections of the hash, too.
2072 \begin_layout Standard
2073 We could then implement snapshots using a similar method, using multiple
2074 different hash tables/free tables.
2077 \begin_layout Subsection
2078 Transactions Cannot Operate in Parallel
2081 \begin_layout Standard
2082 This would be useless for ldb, as it hits the index records with just about
2084 It would add significant complexity in resolving clashes, and cause the
2085 all transaction callers to write their code to loop in the case where the
2086 transactions spuriously failed.
2089 \begin_layout Subsubsection
2093 \begin_layout Standard
2094 We could solve a small part of the problem by providing read-only transactions.
2095 These would allow one write transaction to begin, but it could not commit
2096 until all r/o transactions are done.
2097 This would require a new RO_TRANSACTION_LOCK, which would be upgraded on
2101 \begin_layout Subsection
2102 Default Hash Function Is Suboptimal
2105 \begin_layout Standard
2106 The Knuth-inspired multiplicative hash used by tdb is fairly slow (especially
2107 if we expand it to 64 bits), and works best when the hash bucket size is
2108 a prime number (which also means a slow modulus).
2109 In addition, it is highly predictable which could potentially lead to a
2110 Denial of Service attack in some TDB uses.
2113 \begin_layout Subsubsection
2117 \begin_layout Standard
2118 The Jenkins lookup3 hash
2122 \begin_layout Plain Layout
2123 http://burtleburtle.net/bob/c/lookup3.c
2128 is a fast and superbly-mixing hash.
2129 It's used by the Linux kernel and almost everything else.
2130 This has the particular properties that it takes an initial seed, and produces
2131 two 32 bit hash numbers, which we can combine into a 64-bit hash.
2134 \begin_layout Standard
2135 The seed should be created at tdb-creation time from some random source,
2136 and placed in the header.
2137 This is far from foolproof, but adds a little bit of protection against
2141 \begin_layout Subsection
2142 \begin_inset CommandInset label
2144 name "Reliable-Traversal-Adds"
2148 Reliable Traversal Adds Complexity
2151 \begin_layout Standard
2152 We lock a record during traversal iteration, and try to grab that lock in
2154 If that grab on delete fails, we simply mark it deleted and continue onwards;
2155 traversal checks for this condition and does the delete when it moves off
2159 \begin_layout Standard
2160 If traversal terminates, the dead record may be left indefinitely.
2163 \begin_layout Subsubsection
2167 \begin_layout Standard
2168 Remove reliability guarantees; see
2169 \begin_inset CommandInset ref
2171 reference "traverse-Proposed-Solution"
2178 \begin_layout Subsection
2179 Fcntl Locking Adds Overhead
2182 \begin_layout Standard
2183 Placing a fcntl lock means a system call, as does removing one.
2184 This is actually one reason why transactions can be faster (everything
2185 is locked once at transaction start).
2186 In the uncontended case, this overhead can theoretically be eliminated.
2189 \begin_layout Subsubsection
2193 \begin_layout Standard
2197 \begin_layout Standard
2198 We tried this before with spinlock support, in the early days of TDB, and
2199 it didn't make much difference except in manufactured benchmarks.
2202 \begin_layout Standard
2203 We could use spinlocks (with futex kernel support under Linux), but it means
2204 that we lose automatic cleanup when a process dies with a lock.
2205 There is a method of auto-cleanup under Linux, but it's not supported by
2206 other operating systems.
2207 We could reintroduce a clear-if-first-style lock and sweep for dead futexes
2208 on open, but that wouldn't help the normal case of one concurrent opener
2210 Increasingly elaborate repair schemes could be considered, but they require
2211 an ABI change (everyone must use them) anyway, so there's no need to do
2212 this at the same time as everything else.
2215 \begin_layout Subsection
2216 Some Transactions Don't Require Durability
2219 \begin_layout Standard
2220 Volker points out that gencache uses a CLEAR_IF_FIRST tdb for normal (fast)
2221 usage, and occasionally empties the results into a transactional TDB.
2222 This kind of usage prioritizes performance over durability: as long as
2223 we are consistent, data can be lost.
2226 \begin_layout Standard
2227 This would be more neatly implemented inside tdb: a
2228 \begin_inset Quotes eld
2232 \begin_inset Quotes erd
2235 transaction commit (ie.
2236 syncless) which meant that data may be reverted on a crash.
2239 \begin_layout Subsubsection
2243 \begin_layout Standard
2247 \begin_layout Standard
2248 Unfortunately any transaction scheme which overwrites old data requires
2249 a sync before that overwrite to avoid the possibility of corruption.
2252 \begin_layout Standard
2253 It seems possible to use a scheme similar to that described in
2254 \begin_inset CommandInset ref
2256 reference "sub:TDB-Does-Not"
2260 ,where transactions are committed without overwriting existing data, and
2261 an array of top-level pointers were available in the header.
2262 If the transaction is
2263 \begin_inset Quotes eld
2267 \begin_inset Quotes erd
2270 then we would not need a sync at all: existing processes would pick up
2271 the new hash table and free list and work with that.
2274 \begin_layout Standard
2275 At some later point, a sync would allow recovery of the old data into the
2276 free lists (perhaps when the array of top-level pointers filled).
2277 On crash, tdb_open() would examine the array of top levels, and apply the
2278 transactions until it encountered an invalid checksum.