9 date 2010.08.02.00.21.43; author rusty; state Exp;
14 date 2010.08.02.00.21.16; author rusty; state Exp;
19 date 2010.05.10.13.09.11; author rusty; state Exp;
24 date 2010.05.10.11.58.37; author rusty; state Exp;
29 date 2010.05.10.05.35.13; author rusty; state Exp;
34 date 2010.05.04.02.29.16; author rusty; state Exp;
49 @#LyX 1.6.5 created this file. For more info see http://www.lyx.org/
54 \use_default_options true
59 \font_typewriter default
60 \font_default_family default
67 \paperfontsize default
75 \paperorientation portrait
78 \paragraph_separation indent
80 \quotes_language english
83 \paperpagestyle default
84 \tracking_changes true
93 TDB2: A Redesigning The Trivial DataBase
97 Rusty Russell, IBM Corporation
104 \begin_layout Abstract
105 The Trivial DataBase on-disk format is 32 bits; with usage cases heading
106 towards the 4G limit, that must change.
107 This required breakage provides an opportunity to revisit TDB's other design
108 decisions and reassess them.
111 \begin_layout Section
115 \begin_layout Standard
116 The Trivial DataBase was originally written by Andrew Tridgell as a simple
117 key/data pair storage system with the same API as dbm, but allowing multiple
118 readers and writers while being small enough (< 1000 lines of C) to include
120 The simple design created in 1999 has proven surprisingly robust and performant
121 , used in Samba versions 3 and 4 as well as numerous other projects.
122 Its useful life was greatly increased by the (backwards-compatible!) addition
123 of transaction support in 2005.
126 \begin_layout Standard
127 The wider variety and greater demands of TDB-using code has lead to some
128 organic growth of the API, as well as some compromises on the implementation.
129 None of these, by themselves, are seen as show-stoppers, but the cumulative
130 effect is to a loss of elegance over the initial, simple TDB implementation.
131 Here is a table of the approximate number of lines of implementation code
132 and number of API functions at the end of each year:
135 \begin_layout Standard
137 <lyxtabular version="3" rows="12" columns="3">
139 <column alignment="center" valignment="top" width="0">
140 <column alignment="center" valignment="top" width="0">
141 <column alignment="center" valignment="top" width="0">
143 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
146 \begin_layout Plain Layout
152 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
155 \begin_layout Plain Layout
161 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" rightline="true" usebox="none">
164 \begin_layout Plain Layout
165 Lines of C Code Implementation
172 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
175 \begin_layout Plain Layout
181 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
184 \begin_layout Plain Layout
190 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
193 \begin_layout Plain Layout
201 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
204 \begin_layout Plain Layout
210 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
213 \begin_layout Plain Layout
219 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
222 \begin_layout Plain Layout
230 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
233 \begin_layout Plain Layout
239 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
242 \begin_layout Plain Layout
248 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
251 \begin_layout Plain Layout
259 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
262 \begin_layout Plain Layout
268 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
271 \begin_layout Plain Layout
277 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
280 \begin_layout Plain Layout
288 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
291 \begin_layout Plain Layout
297 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
300 \begin_layout Plain Layout
306 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
309 \begin_layout Plain Layout
317 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
320 \begin_layout Plain Layout
326 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
329 \begin_layout Plain Layout
335 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
338 \begin_layout Plain Layout
346 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
349 \begin_layout Plain Layout
355 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
358 \begin_layout Plain Layout
364 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
367 \begin_layout Plain Layout
375 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
378 \begin_layout Plain Layout
384 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
387 \begin_layout Plain Layout
393 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
396 \begin_layout Plain Layout
404 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
407 \begin_layout Plain Layout
413 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
416 \begin_layout Plain Layout
422 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
425 \begin_layout Plain Layout
433 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
436 \begin_layout Plain Layout
442 <cell alignment="center" valignment="top" topline="true" leftline="true" usebox="none">
445 \begin_layout Plain Layout
451 <cell alignment="center" valignment="top" topline="true" leftline="true" rightline="true" usebox="none">
454 \begin_layout Plain Layout
462 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
465 \begin_layout Plain Layout
471 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" usebox="none">
474 \begin_layout Plain Layout
480 <cell alignment="center" valignment="top" topline="true" bottomline="true" leftline="true" rightline="true" usebox="none">
483 \begin_layout Plain Layout
497 \begin_layout Standard
498 This review is an attempt to catalog and address all the known issues with
499 TDB and create solutions which address the problems without significantly
500 increasing complexity; all involved are far too aware of the dangers of
501 second system syndrome in rewriting a successful project like this.
504 \begin_layout Section
508 \begin_layout Subsection
509 tdb_open_ex Is Not Expandable
512 \begin_layout Standard
513 The tdb_open() call was expanded to tdb_open_ex(), which added an optional
514 hashing function and an optional logging function argument.
515 Additional arguments to open would require the introduction of a tdb_open_ex2
519 \begin_layout Subsubsection
523 \begin_layout Standard
524 tdb_open() will take a linked-list of attributes:
527 \begin_layout LyX-Code
531 \begin_layout LyX-Code
532 TDB_ATTRIBUTE_LOG = 0,
535 \begin_layout LyX-Code
536 TDB_ATTRIBUTE_HASH = 1
539 \begin_layout LyX-Code
543 \begin_layout LyX-Code
544 struct tdb_attribute_base {
547 \begin_layout LyX-Code
548 enum tdb_attribute attr;
551 \begin_layout LyX-Code
552 union tdb_attribute *next;
555 \begin_layout LyX-Code
559 \begin_layout LyX-Code
560 struct tdb_attribute_log {
563 \begin_layout LyX-Code
564 struct tdb_attribute_base base; /* .attr = TDB_ATTRIBUTE_LOG */
567 \begin_layout LyX-Code
571 \begin_layout LyX-Code
575 \begin_layout LyX-Code
579 \begin_layout LyX-Code
580 struct tdb_attribute_hash {
583 \begin_layout LyX-Code
584 struct tdb_attribute_base base; /* .attr = TDB_ATTRIBUTE_HASH */
587 \begin_layout LyX-Code
588 tdb_hash_func hash_fn;
591 \begin_layout LyX-Code
595 \begin_layout LyX-Code
599 \begin_layout LyX-Code
600 union tdb_attribute {
603 \begin_layout LyX-Code
604 struct tdb_attribute_base base;
607 \begin_layout LyX-Code
608 struct tdb_attribute_log log;
611 \begin_layout LyX-Code
612 struct tdb_attribute_hash hash;
615 \begin_layout LyX-Code
619 \begin_layout Standard
620 This allows future attributes to be added, even if this expands the size
624 \begin_layout Subsection
625 tdb_traverse Makes Impossible Guarantees
628 \begin_layout Standard
629 tdb_traverse (and tdb_firstkey/tdb_nextkey) predate transactions, and it
630 was thought that it was important to guarantee that all records which exist
631 at the start and end of the traversal would be included, and no record
632 would be included twice.
635 \begin_layout Standard
636 This adds complexity (see
637 \begin_inset CommandInset ref
639 reference "Reliable-Traversal-Adds"
643 ) and does not work anyway for records which are altered (in particular,
644 those which are expanded may be effectively deleted and re-added behind
648 \begin_layout Subsubsection
649 \begin_inset CommandInset label
651 name "traverse-Proposed-Solution"
658 \begin_layout Standard
659 Abandon the guarantee.
660 You will see every record if no changes occur during your traversal, otherwise
661 you will see some subset.
662 You can prevent changes by using a transaction or the locking API.
665 \begin_layout Subsection
666 Nesting of Transactions Is Fraught
669 \begin_layout Standard
670 TDB has alternated between allowing nested transactions and not allowing
672 Various paths in the Samba codebase assume that transactions will nest,
673 and in a sense they can: the operation is only committed to disk when the
674 outer transaction is committed.
675 There are two problems, however:
678 \begin_layout Enumerate
679 Canceling the inner transaction will cause the outer transaction commit
680 to fail, and will not undo any operations since the inner transaction began.
681 This problem is soluble with some additional internal code.
684 \begin_layout Enumerate
685 An inner transaction commit can be cancelled by the outer transaction.
686 This is desirable in the way which Samba's database initialization code
687 uses transactions, but could be a surprise to any users expecting a successful
688 transaction commit to expose changes to others.
691 \begin_layout Standard
692 The current solution is to specify the behavior at tdb_open(), with the
693 default currently that nested transactions are allowed.
694 This flag can also be changed at runtime.
697 \begin_layout Subsubsection
701 \begin_layout Standard
702 Given the usage patterns, it seems that the
703 \begin_inset Quotes eld
707 \begin_inset Quotes erd
710 behavior of disallowing nested transactions should become the default.
711 Additionally, it seems the outer transaction is the only code which knows
712 whether inner transactions should be allowed, so a flag to indicate this
713 could be added to tdb_transaction_start.
714 However, this behavior can be simulated with a wrapper which uses tdb_add_flags
715 () and tdb_remove_flags(), so the API should not be expanded for this relatively
719 \begin_layout Subsection
720 Incorrect Hash Function is Not Detected
723 \begin_layout Standard
724 tdb_open_ex() allows the calling code to specify a different hash function
725 to use, but does not check that all other processes accessing this tdb
726 are using the same hash function.
727 The result is that records are missing from tdb_fetch().
730 \begin_layout Subsubsection
734 \begin_layout Standard
735 The header should contain an example hash result (eg.
736 the hash of 0xdeadbeef), and tdb_open_ex() should check that the given
737 hash function produces the same answer, or fail the tdb_open call.
740 \begin_layout Subsection
741 tdb_set_max_dead/TDB_VOLATILE Expose Implementation
744 \begin_layout Standard
745 In response to scalability issues with the free list (
746 \begin_inset CommandInset ref
748 reference "TDB-Freelist-Is"
752 ) two API workarounds have been incorporated in TDB: tdb_set_max_dead()
753 and the TDB_VOLATILE flag to tdb_open.
754 The latter actually calls the former with an argument of
755 \begin_inset Quotes eld
759 \begin_inset Quotes erd
765 \begin_layout Standard
766 This code allows deleted records to accumulate without putting them in the
768 On delete we iterate through each chain and free them in a batch if there
769 are more than max_dead entries.
770 These are never otherwise recycled except as a side-effect of a tdb_repack.
773 \begin_layout Subsubsection
777 \begin_layout Standard
778 With the scalability problems of the freelist solved, this API can be removed.
779 The TDB_VOLATILE flag may still be useful as a hint that store and delete
780 of records will be at least as common as fetch in order to allow some internal
781 tuning, but initially will become a no-op.
784 \begin_layout Subsection
785 \begin_inset CommandInset label
787 name "TDB-Files-Cannot"
791 TDB Files Cannot Be Opened Multiple Times In The Same Process
794 \begin_layout Standard
795 No process can open the same TDB twice; we check and disallow it.
796 This is an unfortunate side-effect of fcntl locks, which operate on a per-file
797 rather than per-file-descriptor basis, and do not nest.
798 Thus, closing any file descriptor on a file clears all the locks obtained
799 by this process, even if they were placed using a different file descriptor!
802 \begin_layout Standard
803 Note that even if this were solved, deadlock could occur if operations were
804 nested: this is a more manageable programming error in most cases.
807 \begin_layout Subsubsection
811 \begin_layout Standard
812 We could lobby POSIX to fix the perverse rules, or at least lobby Linux
813 to violate them so that the most common implementation does not have this
815 This would be a generally good idea for other fcntl lock users.
818 \begin_layout Standard
819 Samba uses a wrapper which hands out the same tdb_context to multiple callers
820 if this happens, and does simple reference counting.
821 We should do this inside the tdb library, which already emulates lock nesting
822 internally; it would need to recognize when deadlock occurs within a single
824 This would create a new failure mode for tdb operations (while we currently
825 handle locking failures, they are impossible in normal use and a process
826 encountering them can do little but give up).
829 \begin_layout Standard
830 I do not see benefit in an additional tdb_open flag to indicate whether
831 re-opening is allowed, as though there may be some benefit to adding a
832 call to detect when a tdb_context is shared, to allow other to create such
836 \begin_layout Subsection
837 TDB API Is Not POSIX Thread-safe
840 \begin_layout Standard
841 The TDB API uses an error code which can be queried after an operation to
842 determine what went wrong.
843 This programming model does not work with threads, unless specific additional
844 guarantees are given by the implementation.
845 In addition, even otherwise-independent threads cannot open the same TDB
847 \begin_inset CommandInset ref
849 reference "TDB-Files-Cannot"
856 \begin_layout Subsubsection
860 \begin_layout Standard
861 Reachitecting the API to include a tdb_errcode pointer would be a great
862 deal of churn; we are better to guarantee that the tdb_errcode is per-thread
863 so the current programming model can be maintained.
866 \begin_layout Standard
867 This requires dynamic per-thread allocations, which is awkward with POSIX
868 threads (pthread_key_create space is limited and we cannot simply allocate
869 a key for every TDB).
872 \begin_layout Standard
873 Internal locking is required to make sure that fcntl locks do not overlap
874 between threads, and also that the global list of tdbs is maintained.
877 \begin_layout Standard
878 The aim is that building tdb with -DTDB_PTHREAD will result in a pthread-safe
879 version of the library, and otherwise no overhead will exist.
882 \begin_layout Subsection
883 *_nonblock Functions And *_mark Functions Expose Implementation
886 \begin_layout Standard
891 \begin_layout Plain Layout
892 Clustered TDB, see http://ctdb.samba.org
897 wishes to operate on TDB in a non-blocking manner.
898 This is currently done as follows:
901 \begin_layout Enumerate
902 Call the _nonblock variant of an API function (eg.
903 tdb_lockall_nonblock).
907 \begin_layout Enumerate
908 Fork a child process, and wait for it to call the normal variant (eg.
912 \begin_layout Enumerate
913 If the child succeeds, call the _mark variant to indicate we already have
918 \begin_layout Enumerate
919 Upon completion, tell the child to release the locks (eg.
923 \begin_layout Enumerate
924 Indicate to tdb that it should consider the locks removed (eg.
928 \begin_layout Standard
929 There are several issues with this approach.
930 Firstly, adding two new variants of each function clutters the API for
931 an obscure use, and so not all functions have three variants.
932 Secondly, it assumes that all paths of the functions ask for the same locks,
933 otherwise the parent process will have to get a lock which the child doesn't
934 have under some circumstances.
935 I don't believe this is currently the case, but it constrains the implementatio
940 \begin_layout Subsubsection
941 \begin_inset CommandInset label
943 name "Proposed-Solution-locking-hook"
950 \begin_layout Standard
951 Implement a hook for locking methods, so that the caller can control the
952 calls to create and remove fcntl locks.
953 In this scenario, ctdbd would operate as follows:
956 \begin_layout Enumerate
957 Call the normal API function, eg tdb_lockall().
960 \begin_layout Enumerate
961 When the lock callback comes in, check if the child has the lock.
962 Initially, this is always false.
964 Otherwise, try to obtain it in non-blocking mode.
965 If that fails, return EWOULDBLOCK.
968 \begin_layout Enumerate
969 Release locks in the unlock callback as normal.
972 \begin_layout Enumerate
973 If tdb_lockall() fails, see if we recorded a lock failure; if so, call the
974 child to repeat the operation.
977 \begin_layout Enumerate
978 The child records what locks it obtains, and returns that information to
982 \begin_layout Enumerate
983 When the child has succeeded, goto 1.
986 \begin_layout Standard
987 This is flexible enough to handle any potential locking scenario, even when
988 lock requirements change.
989 It can be optimized so that the parent does not release locks, just tells
990 the child which locks it doesn't need to obtain.
993 \begin_layout Standard
994 It also keeps the complexity out of the API, and in ctdbd where it is needed.
997 \begin_layout Subsection
998 tdb_chainlock Functions Expose Implementation
1001 \begin_layout Standard
1002 tdb_chainlock locks some number of records, including the record indicated
1004 This gave atomicity guarantees; no-one can start a transaction, alter,
1005 read or delete that key while the lock is held.
1008 \begin_layout Standard
1009 It also makes the same guarantee for any other key in the chain, which is
1010 an internal implementation detail and potentially a cause for deadlock.
1013 \begin_layout Subsubsection
1017 \begin_layout Standard
1019 It would be nice to have an explicit single entry lock which effected no
1021 Unfortunately, this won't work for an entry which doesn't exist.
1022 Thus while chainlock may be implemented more efficiently for the existing
1023 case, it will still have overlap issues with the non-existing case.
1024 So it is best to keep the current (lack of) guarantee about which records
1025 will be effected to avoid constraining our implementation.
1028 \begin_layout Subsection
1029 Signal Handling is Not Race-Free
1032 \begin_layout Standard
1033 The tdb_setalarm_sigptr() call allows the caller's signal handler to indicate
1034 that the tdb locking code should return with a failure, rather than trying
1035 again when a signal is received (and errno == EAGAIN).
1036 This is usually used to implement timeouts.
1039 \begin_layout Standard
1040 Unfortunately, this does not work in the case where the signal is received
1041 before the tdb code enters the fcntl() call to place the lock: the code
1042 will sleep within the fcntl() code, unaware that the signal wants it to
1044 In the case of long timeouts, this does not happen in practice.
1047 \begin_layout Subsubsection
1051 \begin_layout Standard
1052 The locking hooks proposed in
1053 \begin_inset CommandInset ref
1055 reference "Proposed-Solution-locking-hook"
1059 would allow the user to decide on whether to fail the lock acquisition
1061 This allows the caller to choose their own compromise: they could narrow
1062 the race by checking immediately before the fcntl call.
1066 \begin_layout Plain Layout
1067 It may be possible to make this race-free in some implementations by having
1068 the signal handler alter the struct flock to make it invalid.
1069 This will cause the fcntl() lock call to fail with EINVAL if the signal
1070 occurs before the kernel is entered, otherwise EAGAIN.
1078 \begin_layout Subsection
1079 The API Uses Gratuitous Typedefs, Capitals
1082 \begin_layout Standard
1083 typedefs are useful for providing source compatibility when types can differ
1084 across implementations, or arguably in the case of function pointer definitions
1085 which are hard for humans to parse.
1086 Otherwise it is simply obfuscation and pollutes the namespace.
1089 \begin_layout Standard
1090 Capitalization is usually reserved for compile-time constants and macros.
1093 \begin_layout Description
1094 TDB_CONTEXT There is no reason to use this over 'struct tdb_context'; the
1095 definition isn't visible to the API user anyway.
1098 \begin_layout Description
1099 TDB_DATA There is no reason to use this over struct TDB_DATA; the struct
1100 needs to be understood by the API user.
1103 \begin_layout Description
1105 \begin_inset space ~
1108 TDB_DATA This would normally be called 'struct tdb_data'.
1111 \begin_layout Description
1113 \begin_inset space ~
1116 TDB_ERROR Similarly, this would normally be enum tdb_error.
1119 \begin_layout Subsubsection
1123 \begin_layout Standard
1125 Introducing lower case variants would please pedants like myself, but if
1126 it were done the existing ones should be kept.
1127 There is little point forcing a purely cosmetic change upon tdb users.
1130 \begin_layout Subsection
1131 \begin_inset CommandInset label
1133 name "tdb_log_func-Doesnt-Take"
1137 tdb_log_func Doesn't Take The Private Pointer
1140 \begin_layout Standard
1141 For API compatibility reasons, the logging function needs to call tdb_get_loggin
1142 g_private() to retrieve the pointer registered by the tdb_open_ex for logging.
1145 \begin_layout Subsubsection
1149 \begin_layout Standard
1150 It should simply take an extra argument, since we are prepared to break
1154 \begin_layout Subsection
1155 Various Callback Functions Are Not Typesafe
1158 \begin_layout Standard
1159 The callback functions in tdb_set_logging_function (after
1160 \begin_inset CommandInset ref
1162 reference "tdb_log_func-Doesnt-Take"
1166 is resolved), tdb_parse_record, tdb_traverse, tdb_traverse_read and tdb_check
1167 all take void * and must internally convert it to the argument type they
1171 \begin_layout Standard
1172 If this type changes, the compiler will not produce warnings on the callers,
1173 since it only sees void *.
1176 \begin_layout Subsubsection
1180 \begin_layout Standard
1181 With careful use of macros, we can create callback functions which give
1182 a warning when used on gcc and the types of the callback and its private
1184 Unsupported compilers will not give a warning, which is no worse than now.
1185 In addition, the callbacks become clearer, as they need not use void *
1186 for their parameter.
1189 \begin_layout Standard
1190 See CCAN's typesafe_cb module at http://ccan.ozlabs.org/info/typesafe_cb.html
1193 \begin_layout Subsection
1194 TDB_CLEAR_IF_FIRST Must Be Specified On All Opens, tdb_reopen_all Problematic
1197 \begin_layout Standard
1198 The TDB_CLEAR_IF_FIRST flag to tdb_open indicates that the TDB file should
1199 be cleared if the caller discovers it is the only process with the TDB
1201 However, if any caller does not specify TDB_CLEAR_IF_FIRST it will not
1202 be detected, so will have the TDB erased underneath them (usually resulting
1206 \begin_layout Standard
1207 There is a similar issue on fork(); if the parent exits (or otherwise closes
1208 the tdb) before the child calls tdb_reopen_all() to establish the lock
1209 used to indicate the TDB is opened by someone, a TDB_CLEAR_IF_FIRST opener
1210 at that moment will believe it alone has opened the TDB and will erase
1214 \begin_layout Subsubsection
1218 \begin_layout Standard
1219 Remove TDB_CLEAR_IF_FIRST.
1220 Other workarounds are possible, but see
1221 \begin_inset CommandInset ref
1223 reference "TDB_CLEAR_IF_FIRST-Imposes-Performance"
1230 \begin_layout Section
1231 Performance And Scalability Issues
1234 \begin_layout Subsection
1235 \begin_inset CommandInset label
1237 name "TDB_CLEAR_IF_FIRST-Imposes-Performance"
1241 TDB_CLEAR_IF_FIRST Imposes Performance Penalty
1244 \begin_layout Standard
1245 When TDB_CLEAR_IF_FIRST is specified, a 1-byte read lock is placed at offset
1248 While these locks never conflict in normal tdb usage, they do add substantial
1249 overhead for most fcntl lock implementations when the kernel scans to detect
1250 if a lock conflict exists.
1251 This is often a single linked list, making the time to acquire and release
1252 a fcntl lock O(N) where N is the number of processes with the TDB open,
1253 not the number actually doing work.
1256 \begin_layout Standard
1257 In a Samba server it is common to have huge numbers of clients sitting idle,
1258 and thus they have weaned themselves off the TDB_CLEAR_IF_FIRST flag.
1262 \begin_layout Plain Layout
1263 There is a flag to tdb_reopen_all() which is used for this optimization:
1264 if the parent process will outlive the child, the child does not need the
1266 This is a workaround for this very performance issue.
1274 \begin_layout Subsubsection
1278 \begin_layout Standard
1280 It was a neat idea, but even trivial servers tend to know when they are
1281 initializing for the first time and can simply unlink the old tdb at that
1285 \begin_layout Subsection
1286 TDB Files Have a 4G Limit
1289 \begin_layout Standard
1290 This seems to be becoming an issue (so much for
1291 \begin_inset Quotes eld
1295 \begin_inset Quotes erd
1298 !), particularly for ldb.
1301 \begin_layout Subsubsection
1305 \begin_layout Standard
1306 A new, incompatible TDB format which uses 64 bit offsets internally rather
1308 For simplicity of endian conversion (which TDB does on the fly if required),
1309 all values will be 64 bit on disk.
1310 In practice, some upper bits may be used for other purposes, but at least
1311 56 bits will be available for file offsets.
1314 \begin_layout Standard
1315 tdb_open() will automatically detect the old version, and even create them
1316 if TDB_VERSION6 is specified to tdb_open.
1319 \begin_layout Standard
1320 32 bit processes will still be able to access TDBs larger than 4G (assuming
1321 that their off_t allows them to seek to 64 bits), they will gracefully
1322 fall back as they fail to mmap.
1323 This can happen already with large TDBs.
1326 \begin_layout Standard
1327 Old versions of tdb will fail to open the new TDB files (since 28 August
1328 2009, commit 398d0c29290: prior to that any unrecognized file format would
1329 be erased and initialized as a fresh tdb!)
1332 \begin_layout Subsection
1333 TDB Records Have a 4G Limit
1336 \begin_layout Standard
1337 This has not been a reported problem, and the API uses size_t which can
1338 be 64 bit on 64 bit platforms.
1339 However, other limits may have made such an issue moot.
1342 \begin_layout Subsubsection
1346 \begin_layout Standard
1347 Record sizes will be 64 bit, with an error returned on 32 bit platforms
1348 which try to access such records (the current implementation would return
1349 TDB_ERR_OOM in a similar case).
1350 It seems unlikely that 32 bit keys will be a limitation, so the implementation
1351 may not support this (see
1352 \begin_inset CommandInset ref
1354 reference "sub:Records-Incur-A"
1361 \begin_layout Subsection
1362 Hash Size Is Determined At TDB Creation Time
1365 \begin_layout Standard
1366 TDB contains a number of hash chains in the header; the number is specified
1367 at creation time, and defaults to 131.
1368 This is such a bottleneck on large databases (as each hash chain gets quite
1369 long), that LDB uses 10,000 for this hash.
1370 In general it is impossible to know what the 'right' answer is at database
1374 \begin_layout Subsubsection
1378 \begin_layout Standard
1379 After comprehensive performance testing on various scalable hash variants
1383 \begin_layout Plain Layout
1384 http://rusty.ozlabs.org/?p=89 and http://rusty.ozlabs.org/?p=94 This was annoying
1385 because I was previously convinced that an expanding tree of hashes would
1386 be very close to optimal.
1391 , it became clear that it is hard to beat a straight linear hash table which
1392 doubles in size when it reaches saturation.
1393 There are three details which become important:
1396 \begin_layout Enumerate
1397 On encountering a full bucket, we use the next bucket.
1400 \begin_layout Enumerate
1401 Extra hash bits are stored with the offset, to reduce comparisons.
1404 \begin_layout Enumerate
1405 A marker entry is used on deleting an entry.
1408 \begin_layout Standard
1409 The doubling of the table must be done under a transaction; we will not
1410 reduce it on deletion, so it will be an unusual case.
1411 It will either be placed at the head (other entries will be moved out the
1412 way so we can expand).
1413 We could have a pointer in the header to the current hashtable location,
1414 but that pointer would have to be read frequently to check for hashtable
1418 \begin_layout Standard
1419 The locking for this is slightly more complex than the chained case; we
1420 currently have one lock per bucket, and that means we would need to expand
1421 the lock if we overflow to the next bucket.
1422 The frequency of such collisions will effect our locking heuristics: we
1423 can always lock more buckets than we need.
1426 \begin_layout Standard
1427 One possible optimization is to only re-check the hash size on an insert
1431 \begin_layout Subsection
1432 \begin_inset CommandInset label
1434 name "TDB-Freelist-Is"
1438 TDB Freelist Is Highly Contended
1441 \begin_layout Standard
1442 TDB uses a single linked list for the free list.
1443 Allocation occurs as follows, using heuristics which have evolved over
1447 \begin_layout Enumerate
1448 Get the free list lock for this whole operation.
1451 \begin_layout Enumerate
1452 Multiply length by 1.25, so we always over-allocate by 25%.
1455 \begin_layout Enumerate
1456 Set the slack multiplier to 1.
1459 \begin_layout Enumerate
1460 Examine the current freelist entry: if it is > length but < the current
1461 best case, remember it as the best case.
1464 \begin_layout Enumerate
1465 Multiply the slack multiplier by 1.05.
1468 \begin_layout Enumerate
1469 If our best fit so far is less than length * slack multiplier, return it.
1470 The slack will be turned into a new free record if it's large enough.
1473 \begin_layout Enumerate
1474 Otherwise, go onto the next freelist entry.
1477 \begin_layout Standard
1478 Deleting a record occurs as follows:
1481 \begin_layout Enumerate
1482 Lock the hash chain for this whole operation.
1485 \begin_layout Enumerate
1486 Walk the chain to find the record, keeping the prev pointer offset.
1489 \begin_layout Enumerate
1490 If max_dead is non-zero:
1494 \begin_layout Enumerate
1495 Walk the hash chain again and count the dead records.
1498 \begin_layout Enumerate
1499 If it's more than max_dead, bulk free all the dead ones (similar to steps
1500 4 and below, but the lock is only obtained once).
1503 \begin_layout Enumerate
1504 Simply mark this record as dead and return.
1509 \begin_layout Enumerate
1510 Get the free list lock for the remainder of this operation.
1513 \begin_layout Enumerate
1514 \begin_inset CommandInset label
1516 name "right-merging"
1520 Examine the following block to see if it is free; if so, enlarge the current
1521 block and remove that block from the free list.
1522 This was disabled, as removal from the free list was O(entries-in-free-list).
1525 \begin_layout Enumerate
1526 Examine the preceeding block to see if it is free: for this reason, each
1527 block has a 32-bit tailer which indicates its length.
1528 If it is free, expand it to cover our new block and return.
1531 \begin_layout Enumerate
1532 Otherwise, prepend ourselves to the free list.
1535 \begin_layout Standard
1536 Disabling right-merging (step
1537 \begin_inset CommandInset ref
1539 reference "right-merging"
1543 ) causes fragmentation; the other heuristics proved insufficient to address
1544 this, so the final answer to this was that when we expand the TDB file
1545 inside a transaction commit, we repack the entire tdb.
1548 \begin_layout Standard
1549 The single list lock limits our allocation rate; due to the other issues
1550 this is not currently seen as a bottleneck.
1553 \begin_layout Subsubsection
1557 \begin_layout Standard
1558 The first step is to remove all the current heuristics, as they obviously
1559 interact, then examine them once the lock contention is addressed.
1562 \begin_layout Standard
1563 The free list must be split to reduce contention.
1564 Assuming perfect free merging, we can at most have 1 free list entry for
1566 This implies that the number of free lists is related to the size of the
1567 hash table, but as it is rare to walk a large number of free list entries
1568 we can use far fewer, say 1/32 of the number of hash buckets.
1571 \begin_layout Standard
1572 There are various benefits in using per-size free lists (see
1573 \begin_inset CommandInset ref
1575 reference "sub:TDB-Becomes-Fragmented"
1579 ) but it's not clear this would reduce contention in the common case where
1580 all processes are allocating/freeing the same size.
1581 Thus we almost certainly need to divide in other ways: the most obvious
1582 is to divide the file into zones, and using a free list (or set of free
1584 This approximates address ordering.
1587 \begin_layout Standard
1588 Note that this means we need to split the free lists when we expand the
1589 file; this is probably acceptable when we double the hash table size, since
1590 that is such an expensive operation already.
1591 In the case of increasing the file size, there is an optimization we can
1592 use: if we use M in the formula above as the file size rounded up to the
1593 next power of 2, we only need reshuffle free lists when the file size crosses
1594 a power of 2 boundary,
1598 reshuffling the free lists is trivial: we simply merge every consecutive
1602 \begin_layout Standard
1603 The basic algorithm is as follows.
1607 \begin_layout Enumerate
1608 Identify the correct zone.
1611 \begin_layout Enumerate
1612 Lock the corresponding list.
1615 \begin_layout Enumerate
1616 Re-check the zone (we didn't have a lock, sizes could have changed): relock
1620 \begin_layout Enumerate
1621 Place the freed entry in the list for that zone.
1624 \begin_layout Standard
1625 Allocation is a little more complicated, as we perform delayed coalescing
1629 \begin_layout Enumerate
1630 Pick a zone either the zone we last freed into, or based on a
1631 \begin_inset Quotes eld
1635 \begin_inset Quotes erd
1641 \begin_layout Enumerate
1642 Lock the corresponding list.
1645 \begin_layout Enumerate
1646 Re-check the zone: relock if necessary.
1649 \begin_layout Enumerate
1650 If the top entry is -large enough, remove it from the list and return it.
1653 \begin_layout Enumerate
1654 Otherwise, coalesce entries in the list.If there was no entry large enough,
1655 unlock the list and try the next zone.
1658 \begin_layout Enumerate
1659 If no zone satisfies, expand the file.
1662 \begin_layout Standard
1663 This optimizes rapid insert/delete of free list entries by not coalescing
1665 First-fit address ordering ordering seems to be fairly good for keeping
1666 fragmentation low (see
1667 \begin_inset CommandInset ref
1669 reference "sub:TDB-Becomes-Fragmented"
1674 Note that address ordering does not need a tailer to coalesce, though if
1675 we needed one we could have one cheaply: see
1676 \begin_inset CommandInset ref
1678 reference "sub:Records-Incur-A"
1686 \begin_layout Standard
1687 I anticipate that the number of entries in each free zone would be small,
1688 but it might be worth using one free entry to hold pointers to the others
1689 for cache efficiency.
1692 \begin_layout Subsection
1693 \begin_inset CommandInset label
1695 name "sub:TDB-Becomes-Fragmented"
1699 TDB Becomes Fragmented
1702 \begin_layout Standard
1703 Much of this is a result of allocation strategy
1707 \begin_layout Plain Layout
1708 The Memory Fragmentation Problem: Solved? Johnstone & Wilson 1995 ftp://ftp.cs.ute
1709 xas.edu/pub/garbage/malloc/ismm98.ps
1714 and deliberate hobbling of coalescing; internal fragmentation (aka overallocati
1715 on) is deliberately set at 25%, and external fragmentation is only cured
1716 by the decision to repack the entire db when a transaction commit needs
1717 to enlarge the file.
1720 \begin_layout Subsubsection
1724 \begin_layout Standard
1725 The 25% overhead on allocation works in practice for ldb because indexes
1726 tend to expand by one record at a time.
1727 This internal fragmentation can be resolved by having an
1728 \begin_inset Quotes eld
1732 \begin_inset Quotes erd
1735 bit in the header to note entries that have previously expanded, and allocating
1736 more space for them.
1739 \begin_layout Standard
1740 There are is a spectrum of possible solutions for external fragmentation:
1741 one is to use a fragmentation-avoiding allocation strategy such as best-fit
1742 address-order allocator.
1743 The other end of the spectrum would be to use a bump allocator (very fast
1744 and simple) and simply repack the file when we reach the end.
1747 \begin_layout Standard
1748 There are three problems with efficient fragmentation-avoiding allocators:
1749 they are non-trivial, they tend to use a single free list for each size,
1750 and there's no evidence that tdb allocation patterns will match those recorded
1751 for general allocators (though it seems likely).
1754 \begin_layout Standard
1755 Thus we don't spend too much effort on external fragmentation; we will be
1756 no worse than the current code if we need to repack on occasion.
1757 More effort is spent on reducing freelist contention, and reducing overhead.
1760 \begin_layout Subsection
1761 \begin_inset CommandInset label
1763 name "sub:Records-Incur-A"
1767 Records Incur A 28-Byte Overhead
1770 \begin_layout Standard
1771 Each TDB record has a header as follows:
1774 \begin_layout LyX-Code
1778 \begin_layout LyX-Code
1779 tdb_off_t next; /* offset of the next record in the list */
1782 \begin_layout LyX-Code
1783 tdb_len_t rec_len; /* total byte length of record */
1786 \begin_layout LyX-Code
1787 tdb_len_t key_len; /* byte length of key */
1790 \begin_layout LyX-Code
1791 tdb_len_t data_len; /* byte length of data */
1794 \begin_layout LyX-Code
1795 uint32_t full_hash; /* the full 32 bit hash of the key */
1798 \begin_layout LyX-Code
1799 uint32_t magic; /* try to catch errors */
1802 \begin_layout LyX-Code
1803 /* the following union is implied:
1806 \begin_layout LyX-Code
1810 \begin_layout LyX-Code
1811 char record[rec_len];
1814 \begin_layout LyX-Code
1818 \begin_layout LyX-Code
1822 \begin_layout LyX-Code
1823 char data[data_len];
1826 \begin_layout LyX-Code
1830 \begin_layout LyX-Code
1831 uint32_t totalsize; (tailer)
1834 \begin_layout LyX-Code
1838 \begin_layout LyX-Code
1842 \begin_layout LyX-Code
1846 \begin_layout Standard
1847 Naively, this would double to a 56-byte overhead on a 64 bit implementation.
1850 \begin_layout Subsubsection
1854 \begin_layout Standard
1855 We can use various techniques to reduce this for an allocated block:
1858 \begin_layout Enumerate
1859 The 'next' pointer is not required, as we are using a flat hash table.
1862 \begin_layout Enumerate
1863 'rec_len' can instead be expressed as an addition to key_len and data_len
1864 (it accounts for wasted or overallocated length in the record).
1865 Since the record length is always a multiple of 8, we can conveniently
1866 fit it in 32 bits (representing up to 35 bits).
1869 \begin_layout Enumerate
1870 'key_len' and 'data_len' can be reduced.
1871 I'm unwilling to restrict 'data_len' to 32 bits, but instead we can combine
1872 the two into one 64-bit field and using a 5 bit value which indicates at
1873 what bit to divide the two.
1874 Keys are unlikely to scale as fast as data, so I'm assuming a maximum key
1878 \begin_layout Enumerate
1879 'full_hash' is used to avoid a memcmp on the
1880 \begin_inset Quotes eld
1884 \begin_inset Quotes erd
1887 case, but this is diminishing returns after a handful of bits (at 10 bits,
1888 it reduces 99.9% of false memcmp).
1889 As an aside, as the lower bits are already incorporated in the hash table
1890 resolution, the upper bits should be used here.
1893 \begin_layout Enumerate
1894 'magic' does not need to be enlarged: it currently reflects one of 5 values
1895 (used, free, dead, recovery, and unused_recovery).
1896 It is useful for quick sanity checking however, and should not be eliminated.
1899 \begin_layout Enumerate
1900 'tailer' is only used to coalesce free blocks (so a block to the right can
1901 find the header to check if this block is free).
1902 This can be replaced by a single 'free' bit in the header of the following
1903 block (and the tailer only exists in free blocks).
1907 \begin_layout Plain Layout
1908 This technique from Thomas Standish.
1909 Data Structure Techniques.
1910 Addison-Wesley, Reading, Massachusetts, 1980.
1915 The current proposed coalescing algorithm doesn't need this, however.
1918 \begin_layout Standard
1919 This produces a 16 byte used header like this:
1922 \begin_layout LyX-Code
1923 struct tdb_used_record {
1926 \begin_layout LyX-Code
1927 uint32_t magic : 16,
1930 \begin_layout LyX-Code
1934 \begin_layout LyX-Code
1938 \begin_layout LyX-Code
1942 \begin_layout LyX-Code
1943 uint32_t extra_octets;
1946 \begin_layout LyX-Code
1947 uint64_t key_and_data_len;
1950 \begin_layout LyX-Code
1954 \begin_layout Standard
1955 And a free record like this:
1958 \begin_layout LyX-Code
1959 struct tdb_free_record {
1962 \begin_layout LyX-Code
1963 uint32_t free_magic;
1966 \begin_layout LyX-Code
1967 uint64_t total_length;
1970 \begin_layout LyX-Code
1974 \begin_layout LyX-Code
1978 \begin_layout LyX-Code
1982 \begin_layout LyX-Code
1986 \begin_layout Subsection
1987 Transaction Commit Requires 4 fdatasync
1990 \begin_layout Standard
1991 The current transaction algorithm is:
1994 \begin_layout Enumerate
1995 write_recovery_data();
1998 \begin_layout Enumerate
2002 \begin_layout Enumerate
2003 write_recovery_header();
2006 \begin_layout Enumerate
2010 \begin_layout Enumerate
2011 overwrite_with_new_data();
2014 \begin_layout Enumerate
2018 \begin_layout Enumerate
2019 remove_recovery_header();
2022 \begin_layout Enumerate
2026 \begin_layout Standard
2027 On current ext3, each sync flushes all data to disk, so the next 3 syncs
2028 are relatively expensive.
2029 But this could become a performance bottleneck on other filesystems such
2033 \begin_layout Subsubsection
2037 \begin_layout Standard
2038 Neil Brown points out that this is overzealous, and only one sync is needed:
2041 \begin_layout Enumerate
2042 Bundle the recovery data, a transaction counter and a strong checksum of
2046 \begin_layout Enumerate
2047 Strong checksum that whole bundle.
2050 \begin_layout Enumerate
2051 Store the bundle in the database.
2054 \begin_layout Enumerate
2055 Overwrite the oldest of the two recovery pointers in the header (identified
2056 using the transaction counter) with the offset of this bundle.
2059 \begin_layout Enumerate
2063 \begin_layout Enumerate
2064 Write the new data to the file.
2067 \begin_layout Standard
2068 Checking for recovery means identifying the latest bundle with a valid checksum
2069 and using the new data checksum to ensure that it has been applied.
2070 This is more expensive than the current check, but need only be done at
2072 For running databases, a separate header field can be used to indicate
2073 a transaction in progress; we need only check for recovery if this is set.
2076 \begin_layout Subsection
2077 \begin_inset CommandInset label
2079 name "sub:TDB-Does-Not"
2083 TDB Does Not Have Snapshot Support
2086 \begin_layout Subsubsection
2090 \begin_layout Standard
2092 At some point you say
2093 \begin_inset Quotes eld
2097 \begin_inset Quotes erd
2103 \begin_layout Standard
2104 But as a thought experiment, if we implemented transactions to only overwrite
2105 free entries (this is tricky: there must not be a header in each entry
2106 which indicates whether it is free, but use of presence in metadata elsewhere),
2107 and a pointer to the hash table, we could create an entirely new commit
2108 without destroying existing data.
2109 Then it would be easy to implement snapshots in a similar way.
2112 \begin_layout Standard
2113 This would not allow arbitrary changes to the database, such as tdb_repack
2114 does, and would require more space (since we have to preserve the current
2115 and future entries at once).
2116 If we used hash trees rather than one big hash table, we might only have
2117 to rewrite some sections of the hash, too.
2120 \begin_layout Standard
2121 We could then implement snapshots using a similar method, using multiple
2122 different hash tables/free tables.
2125 \begin_layout Subsection
2126 Transactions Cannot Operate in Parallel
2129 \begin_layout Standard
2130 This would be useless for ldb, as it hits the index records with just about
2132 It would add significant complexity in resolving clashes, and cause the
2133 all transaction callers to write their code to loop in the case where the
2134 transactions spuriously failed.
2137 \begin_layout Subsubsection
2141 \begin_layout Standard
2142 We could solve a small part of the problem by providing read-only transactions.
2143 These would allow one write transaction to begin, but it could not commit
2144 until all r/o transactions are done.
2145 This would require a new RO_TRANSACTION_LOCK, which would be upgraded on
2149 \begin_layout Subsection
2150 Default Hash Function Is Suboptimal
2153 \begin_layout Standard
2154 The Knuth-inspired multiplicative hash used by tdb is fairly slow (especially
2155 if we expand it to 64 bits), and works best when the hash bucket size is
2156 a prime number (which also means a slow modulus).
2157 In addition, it is highly predictable which could potentially lead to a
2158 Denial of Service attack in some TDB uses.
2161 \begin_layout Subsubsection
2165 \begin_layout Standard
2166 The Jenkins lookup3 hash
2170 \begin_layout Plain Layout
2171 http://burtleburtle.net/bob/c/lookup3.c
2176 is a fast and superbly-mixing hash.
2177 It's used by the Linux kernel and almost everything else.
2178 This has the particular properties that it takes an initial seed, and produces
2179 two 32 bit hash numbers, which we can combine into a 64-bit hash.
2182 \begin_layout Standard
2183 The seed should be created at tdb-creation time from some random source,
2184 and placed in the header.
2185 This is far from foolproof, but adds a little bit of protection against
2189 \begin_layout Subsection
2190 \begin_inset CommandInset label
2192 name "Reliable-Traversal-Adds"
2196 Reliable Traversal Adds Complexity
2199 \begin_layout Standard
2200 We lock a record during traversal iteration, and try to grab that lock in
2202 If that grab on delete fails, we simply mark it deleted and continue onwards;
2203 traversal checks for this condition and does the delete when it moves off
2207 \begin_layout Standard
2208 If traversal terminates, the dead record may be left indefinitely.
2211 \begin_layout Subsubsection
2215 \begin_layout Standard
2216 Remove reliability guarantees; see
2217 \begin_inset CommandInset ref
2219 reference "traverse-Proposed-Solution"
2226 \begin_layout Subsection
2227 Fcntl Locking Adds Overhead
2230 \begin_layout Standard
2231 Placing a fcntl lock means a system call, as does removing one.
2232 This is actually one reason why transactions can be faster (everything
2233 is locked once at transaction start).
2234 In the uncontended case, this overhead can theoretically be eliminated.
2237 \begin_layout Subsubsection
2241 \begin_layout Standard
2245 \begin_layout Standard
2246 We tried this before with spinlock support, in the early days of TDB, and
2247 it didn't make much difference except in manufactured benchmarks.
2250 \begin_layout Standard
2251 We could use spinlocks (with futex kernel support under Linux), but it means
2252 that we lose automatic cleanup when a process dies with a lock.
2253 There is a method of auto-cleanup under Linux, but it's not supported by
2254 other operating systems.
2255 We could reintroduce a clear-if-first-style lock and sweep for dead futexes
2256 on open, but that wouldn't help the normal case of one concurrent opener
2258 Increasingly elaborate repair schemes could be considered, but they require
2259 an ABI change (everyone must use them) anyway, so there's no need to do
2260 this at the same time as everything else.
2263 \begin_layout Subsection
2264 Some Transactions Don't Require Durability
2267 \begin_layout Standard
2268 Volker points out that gencache uses a CLEAR_IF_FIRST tdb for normal (fast)
2269 usage, and occasionally empties the results into a transactional TDB.
2270 This kind of usage prioritizes performance over durability: as long as
2271 we are consistent, data can be lost.
2274 \begin_layout Standard
2275 This would be more neatly implemented inside tdb: a
2276 \begin_inset Quotes eld
2280 \begin_inset Quotes erd
2283 transaction commit (ie.
2284 syncless) which meant that data may be reverted on a crash.
2287 \begin_layout Subsubsection
2291 \begin_layout Standard
2295 \begin_layout Standard
2296 Unfortunately any transaction scheme which overwrites old data requires
2297 a sync before that overwrite to avoid the possibility of corruption.
2300 \begin_layout Standard
2301 It seems possible to use a scheme similar to that described in
2302 \begin_inset CommandInset ref
2304 reference "sub:TDB-Does-Not"
2308 ,where transactions are committed without overwriting existing data, and
2309 an array of top-level pointers were available in the header.
2310 If the transaction is
2311 \begin_inset Quotes eld
2315 \begin_inset Quotes erd
2318 then we would not need a sync at all: existing processes would pick up
2319 the new hash table and free list and work with that.
2322 \begin_layout Standard
2323 At some later point, a sync would allow recovery of the old data into the
2324 free lists (perhaps when the array of top-level pointers filled).
2325 On crash, tdb_open() would examine the array of top levels, and apply the
2326 transactions until it encountered an invalid checksum.
2336 @Soft transaction commit
2341 \author "Rusty Russell,,,"
2344 \change_deleted 0 1280141199
2346 \change_inserted 0 1280141202
2352 \change_inserted 0 1280140902
2357 \change_inserted 0 1280140661
2361 \change_inserted 0 1280140703
2364 \change_inserted 0 1280708312
2367 \change_inserted 0 1280708400
2370 \change_inserted 0 1280140836
2373 \change_inserted 0 1280708255
2376 \change_inserted 0 1280708374
2379 \change_inserted 0 1280141181
2382 \change_inserted 0 1280141345
2403 @Transaction and freelist rethink.
2408 \author "Rusty Russell,,,"
2414 behavior of disallowing
2415 \change_inserted 0 1272940179
2418 transactions should become the default.
2420 \change_inserted 0 1272944650
2424 \change_inserted 0 1272944763
2433 \change_inserted 0 1273478114
2440 \change_deleted 0 1273469807
2442 \change_inserted 0 1273469810
2446 \change_deleted 0 1273469815
2449 to reduce contention.
2451 \change_inserted 0 1273470006
2455 \change_inserted 0 1273492055
2458 \change_inserted 0 1273483888
2464 \change_deleted 0 1272942055
2465 There are various ways to organize these lisys, but because we want to be
2466 able to quickly identify which free list an entry is in, and reduce the
2467 number of locks required for merging, we will use zoning (eg.
2468 each free list covers some fixed fraction of the file).
2470 \change_inserted 0 1273484187
2474 \change_deleted 0 1273484194
2476 \change_inserted 0 1273484194
2482 Identify the correct
2483 \change_deleted 0 1273482856
2485 \change_inserted 0 1273482857
2492 \change_inserted 0 1273482895
2496 \change_inserted 0 1273482863
2500 \change_inserted 0 1273482909
2504 \change_deleted 0 1273482885
2506 \change_inserted 0 1273482888
2509 lace the freed entry
2510 \change_deleted 0 1273492415
2512 \change_inserted 0 1273492415
2513 in the list for that zone
2518 Allocation is a little more complicated, as we
2519 \change_deleted 0 1273483240
2520 merge entries as we walk the list:
2521 \change_inserted 0 1273484250
2522 perform delayed coalescing at this point:
2528 \change_deleted 0 1273482955
2530 \change_inserted 0 1273482957
2534 \change_deleted 0 1273482962
2536 \change_inserted 0 1273482962
2540 \change_deleted 0 1273482966
2542 \change_inserted 0 1273482966
2549 \change_inserted 0 1273482980
2551 \change_deleted 0 1273482973
2555 \change_inserted 0 1273482982
2559 \change_inserted 0 1273483084
2565 \begin_layout Enumerate
2567 \change_deleted 0 1273492155
2569 \change_inserted 0 1273492159
2572 remove it from the list and return it.
2575 \begin_layout Enumerate
2577 \change_inserted 0 1273492206
2578 coalesce entries in the list.
2579 \change_deleted 0 1273492200
2580 examine the entry to the right of it in the file.
2585 \begin_layout Enumerate
2587 \change_deleted 0 1273492200
2588 If that entry is in a different list, lock that list too.
2591 \begin_layout Enumerate
2593 \change_deleted 0 1273492200
2594 If we had to place a new lock, re-check that the entry is free.
2597 \begin_layout Enumerate
2599 \change_deleted 0 1273492200
2600 Remove that entry from its free list and expand this entry to cover it.
2603 \begin_layout Enumerate
2605 \change_deleted 0 1273485554
2610 \begin_layout Enumerate
2612 \change_inserted 0 1273485311
2613 If there was no entry large enough, unlock the list and try the next zone.
2617 \change_deleted 0 1273483646
2618 Repeat step 3 with each entry in the list.
2624 \change_deleted 0 1273483668
2625 Unlock the list and repeat step 2 with the next list.
2631 \change_deleted 0 1273483671
2633 \change_inserted 0 1273483671
2636 satisfies, expand the file.
2639 This optimizes rapid insert/delete of free list entries
2640 \change_inserted 0 1273485794
2641 by not coalescing them all the time.
2642 \change_deleted 0 1273483685
2643 , and allows us to get rid of the tailer altogether
2647 \change_inserted 0 1273492299
2650 \change_deleted 0 1273476840
2652 \begin_inset Quotes eld
2656 \begin_inset Quotes erd
2659 free entries is more difficult: the 25% overhead works in practice for
2660 ldb because indexes tend to expand by one record at a time.
2661 This can be resolved by having an
2662 \begin_inset Quotes eld
2666 \begin_inset Quotes erd
2669 bit in the header to note entries that have previously expanded, and allocating
2670 more space for them.
2672 \begin_inset Quotes eld
2676 \begin_inset Quotes erd
2679 algorithm should be implemented or first-fit used is still unknown: we
2680 will determine this once these other ideas are implemented.
2681 \change_inserted 0 1273483750
2685 \begin_layout Standard
2687 \change_inserted 0 1273492450
2690 \change_inserted 0 1273470441
2693 \change_inserted 0 1273476556
2696 \change_inserted 0 1273470423
2702 \change_inserted 0 1273476847
2705 \change_inserted 0 1273476886
2708 \change_inserted 0 1273477233
2711 \change_inserted 0 1273477534
2714 \change_inserted 0 1273482700
2717 \change_inserted 0 1273478079
2720 \change_inserted 0 1273477839
2723 \change_inserted 0 1273477925
2726 \change_inserted 0 1273477925
2729 \change_inserted 0 1273477925
2732 \change_inserted 0 1273477925
2735 \change_inserted 0 1273477925
2738 \change_inserted 0 1273477925
2741 \change_inserted 0 1273477925
2744 \change_inserted 0 1273477925
2747 \change_inserted 0 1273477925
2750 \change_inserted 0 1273477925
2753 \change_inserted 0 1273477925
2756 \change_inserted 0 1273477925
2759 \change_inserted 0 1273477925
2762 \change_inserted 0 1273477925
2765 \change_inserted 0 1273477925
2768 \change_inserted 0 1273477925
2771 \change_inserted 0 1273477925
2774 \change_inserted 0 1273477925
2777 \change_inserted 0 1273492522
2780 \change_inserted 0 1273492530
2783 \change_inserted 0 1273492546
2786 \change_inserted 0 1273478239
2789 \change_inserted 0 1273479960
2792 \change_inserted 0 1273480265
2795 \change_inserted 0 1273480354
2798 \change_inserted 0 1273478968
2801 \change_inserted 0 1273492604
2804 \change_inserted 0 1273479572
2810 \change_inserted 0 1273480282
2813 \change_inserted 0 1273478931
2816 \change_inserted 0 1273481549
2819 \change_inserted 0 1273481557
2822 \change_inserted 0 1273480307
2825 \change_inserted 0 1273480335
2828 \change_inserted 0 1273479897
2831 \change_inserted 0 1273479653
2834 \change_inserted 0 1273480371
2837 \change_inserted 0 1273480464
2840 \change_inserted 0 1273480399
2843 \change_inserted 0 1273480425
2846 \change_inserted 0 1273480453
2849 \change_inserted 0 1273480455
2852 \change_inserted 0 1273480450
2855 \change_inserted 0 1273480452
2857 \change_inserted 0 1273478830
2861 \change_deleted 0 1273481604
2862 In theory, we could get away with 2: one after we write the new data, and
2863 one to somehow atomically change over to it.
2864 \change_inserted 0 1273481632
2867 \change_inserted 0 1273481724
2870 \change_inserted 0 1273481713
2873 \change_inserted 0 1273481717
2876 \change_inserted 0 1273481730
2879 \change_inserted 0 1273481736
2882 \change_inserted 0 1273481744
2885 \change_inserted 0 1273481748
2888 \change_inserted 0 1273482185
2891 \change_inserted 0 1273482259
2894 \change_deleted 0 1273481848
2896 Trying to rewrite the transaction code is a separate experiment, which
2897 I encourage someone else to do.
2898 At some point you say
2899 \begin_inset Quotes eld
2903 \begin_inset Quotes erd
2909 \begin_layout Standard
2911 \change_deleted 0 1273481848
2912 But as a thought experiment:
2917 \begin_layout Standard
2919 \change_deleted 0 1273481788
2920 Say there was a pointer in the header which said where the hash table and
2921 free list tables were, and that no blocks were labeled with whether they
2922 were free or not (it had to be derived from what list they were in).
2923 We could create new hash table and free list in some free space, and populate
2924 it as we want the post-committed state to look.
2925 Then we sync, then we switch the offset in the header, then we sync again.
2928 \begin_layout Standard
2930 \change_deleted 0 1273481788
2931 This would not allow arbitrary changes to the database, such as tdb_repack
2932 does, and would require more space (since we have to preserve the current
2933 and future entries at once).
2934 If we used hash trees rather than one big hash table, we might only have
2935 to rewrite some sections of the hash, too.
2936 \change_inserted 0 1273481854
2940 \begin_layout Standard
2942 \change_inserted 0 1273482102
2945 \change_inserted 0 1273482061
2948 \change_inserted 0 1273482063
2951 \change_inserted 0 1273482072
2954 \change_inserted 0 1273482139
2957 \change_inserted 0 1273482364
2960 \change_inserted 0 1273482163
2963 \change_inserted 0 1273482493
2966 \change_inserted 0 1273482536
2972 \change_inserted 0 1273482641
2975 \change_inserted 0 1273481827
2979 \change_inserted 0 1273481829
2982 implement snapshots using a similar method
2983 \change_deleted 0 1273481838
2985 \change_inserted 0 1273481840
2988 using multiple different hash tables/free tables.
2994 @After first feedback (Ronnie & Volker)
3000 The free list should be split into multiple lists to reduce contention.
3005 The algorithm for freeing is simple:
3008 Identify the correct free list.
3011 Lock the list, and place the freed entry at the head.
3014 Allocation is a little more complicated, as we merge entries as we walk
3018 Pick a free list; either the list we last freed onto, or based on a
3024 If the top entry is well-sized, remove it from the list and return it.
3027 Otherwise, examine the entry to the right of it in the file.
3038 If no list satisfies, expand the file.
3041 This optimizes rapid insert/delete of free list entries, and allows us to
3042 get rid of the tailer altogether.
3046 \change_inserted 0 1272941474
3049 \change_inserted 0 1272942759
3050 There are various ways to organize these lists, but because we want to be
3051 able to quickly identify which free list an entry is in, and reduce the
3052 number of locks required for merging, we will use zoning (eg.
3053 each of the N free lists in a tdb file of size M covers a fixed fraction
3055 Note that this means we need to reshuffle the free lists when we expand
3056 the file; this is probably acceptable when we double the hash table size,
3057 since that is such an expensive operation already.
3058 In the case of increasing the file size, there is an optimization we can
3059 use: if we use M in the formula above as the file size rounded up to the
3060 next power of 2, we only need reshuffle free lists when the file size crosses
3061 a power of 2 boundary,
3065 reshuffling the free lists is trivial: we simply merge every consecutive
3079 We could implement snapshots using a similar method to the above, only using
3080 multiple different hash tables/free tables.
3091 #LyX 1.6.4 created this file. For more info see http://www.lyx.org/
3094 \tracking_changes false
3095 \output_changes false
3099 behavior of disallowing transactions should become the default.
3104 The algorithm for freeing is simple:
projects / ccan / blob