/*! @arch_page arch-log-file Log File Format

This page assumes familiarity with the logging subsystem. Please see
@ref arch-logging "Logging" for a description of that subsystem.

Each log file begins with a fixed length header, followed by a set of
variable length log records. The fixed length header contains information
necessary for WiredTiger to determine that a file is a valid log file.
The header contains a magic number in the first 32 bits, the log version
number and the configured maximum log file size.

When a new log file is created WiredTiger must synchronously write out the header before allowing
any user records to be written to the file. The content of the file header is
identical for every log file.  This fact allows for pre-allocation of log files
so that user threads that happen to be writing out log records that require a log
file switch are usually not penalized with expensive I/O operations. The typical
log file switch is a rename instead. In addition to writing out the header, pre-allocation
also allocates the space for the maximum size of the log file so that the risk
of out of space errors is minimized. Pre-allocation is done with an internal
thread as described in @ref log_threads.

Log files from log version 1 are generated by releases before WiredTiger version
3.0.0. In log version 1, user records start immediately after the header.
All log files from log version 2 onward write a system log record after
the header as the first record in the log file. Writing the system record
is part of creating the new log file.

All records in the log, including the header, are subject to the minimum record
size. Typically that is 128 bytes. That value may be changed if direct I/O for
logging is turned on. When enabling direct I/O via \c direct_io=log to ::wiredtiger_open
then the minimum alignment is the value specified for \c buffer_alignment.
In all other cases it is 128 bytes.

The reason that 128 bytes was chosen as the minimum record size was to eliminate any
possibility of false sharing in memory and invalidating cache lines when multiple
threads are writing their log records to the memory buffers in parallel. False sharing
would potentially impact performance.

From version 2 onward the first record in the log file, typically at offset 128 in the
file, is a special system log
record that contains the LSN of the end of the previous log file. For the first
log file that value is an invalid LSN. For later log files the LSN indicates the end
of the previous file so that recovery can detect missing log records and holes in
log files that appear at the end of a file.

As described in @ref log_subsystem, multiple threads are writing records to the log
in a lock free manner and multiple log buffer slots may be in flight at any given time.
A hole can be generated in a log file if a buffer with a later LSN is written before
a buffer with an earlier LSN. That can also happen at a log file boundary and that is why
knowing the LSN at the end of the previous log file is critical to recovery.

The user can choose the maximum log file size via \c log=(file_max=size) configuration
to the ::wiredtiger_open call. Records written in the log are varying length
depending on the data written. In typical usage, the system will choose to switch
log files before writing a log buffer that exceeds the configured file size. However it
is possible that a single record itself could be larger than the configured file size.
In that case the system must allow that record to exceed the maximum file size. But it
will be the only record in that log file.
*/
