$LogFile Restart Area and LSNs Explained

TL;DR. The first two pages of $LogFile are RSTR restart pages. Each holds a restart area: the current LSN, the log size, the number of sequence-number bits, flags, and a client record for NTFS pointing to the latest checkpoint. An LSN is a 64-bit number whose low bits are the record's offset in 8-byte units and whose high bits are a wrap counter; with seq_bits from the restart area, offset = (LSN << seq_bits) >> (seq_bits − 3). LSNs only grow, so they order everything in the log — and the same LSNs appear in $MFT record headers.

If you ever need to explain why a parser says "LSN 115720 → 117880" or check a record by hand in a hex editor, this is the part of the format you need. The page-level layout is in $LogFile format 1.1 vs 2.0.

The restart page header

Two copies at offsets 0 and one system page later (usually 0x1000). They are not necessarily in sync (dfir.ru); a reader validates both and keeps the one with the higher current LSN. Offsets per libfsntfs and ntfs3:

Apply the update sequence fix-ups before reading anything past the first sector.

The restart area

At the offset given in 0x18:

The NTFS client record

Each client slot is 0xA0 bytes; NTFS is normally the only client:

Checkpoints: record type 2

The client restart LSN points to a log record of type 2 (client restart). For NTFS, its payload (NTFS_RESTART in ntfs3) lists the LSNs and lengths of the table dumps written at that checkpoint:

Recovery starts from here: it reloads the open attribute table and friends, then scans forward. For an analyst, the checkpoint explains why OpenAttributeTableDump and AttributeNamesDump records appear regularly, and why a parser needs them to name the attribute a record targets.

LSN anatomy

An LSN is 64 bits split in two:

 63                         (64 - seq_bits)                    0
 +-------------------------+-----------------------------------+
 |     sequence number     |  offset in 8-byte units           |
 +-------------------------+-----------------------------------+

The sequence number grows each time the log wraps, which keeps LSNs strictly increasing even though offsets repeat. The split depends on the log size. ntfs3 derives it as file_data_bits = log2(log_size) − 3 and seq_bits = 64 − file_data_bits:

Always read seq_bits from the restart area rather than computing it.

From LSN to file offset

offset = (LSN << seq_bits) >> (seq_bits - 3)

The left shift drops the sequence number; the right shift by seq_bits − 3 brings the offset field back and multiplies it by 8. dfir.ru gives a worked example: with 44 sequence bits, LSN 2124332 has sequence number 2 and an offset of 27180 eight-byte units, i.e. byte 217440.

A robust parser can use this in reverse. Instead of walking page chains, it scans each RCRD page for 8-byte-aligned headers whose LSN maps exactly to their own offset. That check rejects random bytes and keeps working when pages in between are damaged — it is how the in-browser $LogFile parser finds records. Records that do not fit in the rest of a page continue after the header of the next page (and wrap from the end of the file to the start of the circular area); a continuation page older than the record means the rest was overwritten, and the record is flagged incomplete.

LSNs outside the $LogFile

• Every FILE record in the $MFT stores, at header offset 0x08, the LSN of the last logged change to that record — one of the links in David Cowen's NTFS TriForce. If that LSN is inside the log's current range, the change that produced the current FILE record is still in the log.
• Index buffers (INDX) also carry an LSN in their header.

Comparing an $MFT record's LSN with the log's lowest LSN tells you immediately whether its latest change can still be found.

What the numbers tell you in practice

Frequently asked questions

What is an LSN in NTFS?

A log sequence number is a 64-bit identifier given to every $LogFile record. Its low bits encode the record's position in the file in 8-byte units and its high bits a sequence number that grows each time the log wraps, so LSNs always increase.

How do I convert a $LogFile LSN to a file offset?

Read the sequence-number bit count from the restart area, then compute (LSN << seq_bits) >> (seq_bits - 3). That keeps the low 64 - seq_bits bits and multiplies them by 8, which gives the byte offset of the record header in the file.

Further reading

• Linux kernel, fs/ntfs3/fslog.c — RESTART_HDR, RESTART_AREA, CLIENT_REC, NTFS_RESTART, lsn_to_vbo.
• Maxim Suhanov, How the $LogFile works?

Related articles

• NTFS $LogFile redo/undo operations explained
• $LogFile format 1.1 vs 2.0
• NTFS $LogFile forensics: the complete guide