Berkeley DB 源代码分析 (7) --- 事务和日志 (2)

这篇和上篇一样，也是含有一些wiki格式控制字符，看的时候直接忽略这些格式字符。

= Logging subsystem =

== Architecture ==

Log subsystem consists of one log buffer, and several log files, each has a unique file number.  Log buffer and log files contains
log records.  Log records has a loghdr and a data part, hdr contains the admin info about this logrec, and the checksum of log
rec data part(loghdr not checksumed), logrec data part Log records contains full info about an event that just happened(so the
data they contain may vary a lot, some log recs are huge, some are tiny), other parts of the db need to explicitly construct the
required log record and log the event, in order to do recovery. Log recs are appended to the last log file one by one, each log
record has an LSN(log sequence number), when one log file is full (set_log_size, and a log record is not partly stored in multiple
log files), another is created, with incremented index. Logically all log files make up a huge log.

log sequence number consists of two parts---(fileno, infile-offset), both fields are increasing only. LSNs are used to
identify each log record and its exact position, to identify relative time in mvcc mpool algorithm, and to identify those objects
related to the events recorded in the corresponding log record, for example, when a page is created, this event is logged in a log
record with LSN "lsn", then the "lsn" is also written into that page's header, so that we can find out when(relative time) that
page is created, and more info, in the log record; and this lsn will be used to maintain connection between this page and the
logs, when later this page is modified or deleted, we use the "lsn" in its header to identify exactly which page those events
happened to. During normal run of db, log recs are only appended to log files, and they are read out only when we are doing a recovery.
At that time, log recs are accessed using a log cursor,