File - $LogFile

概述

属性

文件结构

未命名数据流

对日志文件结构了解很少

注意：

其它信息

日志区域是由多个 4KB 的日志记录组成的序列，每个日志记录结构如下：

偏移量（长度） 内容

0 （ 4 ）      魔术字 ‘ RCRD'

1E （ 12 ）    这个值是固定的

据推测，日志记录是由大小不同且结构未知的记录组成的序列，它包含处理事务的记录以保证在系统瘫痪时数据的完整性。它包含 2 个重新启动区的copy和一个所谓“无限”的日志区。

当你要把一个文件写到盘上的时候，系统要做两件事，第一，写文件本身的数据，第二，更新跟文件系统有关的一些数据（比方说文件创建时间）。

如果此操作完成，可以确认文件被写到存储单元上，并且文件系统处于正常状态。

如果此操作未完成（例如电源故障，系统瘫痪等），则文件系统处于非正常状态。把它恢复到正常（健全）状态的唯一途径（这种恢复过程称为“回滚”）是在一个特殊文件里记录日志，这个日志文件会记录某个操作的成功与否。

在系统故障后第一次进入磁盘时，系统读取日志文件并“回滚”到最后一次操作开始前的状态

当系统写日志文件时，操作必须是自动且即时的。

可以在很短的时间内把卷恢复到正常状态，恢复时间与磁盘大小无关，只与失败任务的复杂程度有关。

注意：这个操作并不是由 WINDOWS NT 的 chkdsk 工具执行的，而是由系统执行：这种正规而可靠的操作是 NTFS 文件系统的特点。

Log file organization:

Two restart areas present in the first two pages (restart pages). When

the volume is unmounted they should be identical.

These are followed by log records organized in pages headed by a record

header going up to log file size. Not all pages contain log records when a

volume is first formatted, but as the volume ages, all records will be used.

When the log file fills up, the records at the beginning are purged (by

modifying the oldest_lsn to a higher value presumably) and writing begins

at the beginning of the file. Effectively, the log file is viewed as a

circular entity.

Log file restart page header (begins the restart area).

struct {

NTFS_RECORD; The magic is "RSTR".

__u64 chkdsk_lsn; The check disk log file sequence number for

this restart page. Only used when the

magic is changed to "CHKD". = 0

__u32 system_page_size; Byte size of system pages, has to be >= 512

and a power of 2. Use this to calculate the

required size of the usa and add this to the

ntfs.usa_offset value. Then verify that the

result is less than the value of the

restart_offset. = 0x1000

__u32 log_page_size; Byte size of log file records, has to be

>= 512 and a power of 2. = 0x1000

__u16 restart_offset; Byte offset from the start of the record to

the restart record. Value has to be aligned

to 8-byte boundary. = 0x30

__s16 minor_ver; Log file minor version. Only check if major

version is 1. (=1 but >=1 is treated the

same and <=0 is also ok)

__u16 major_ver; Log file major version (=1 but =0 is ok)

} RESTART_PAGE_HEADER;

Log file restart area record. The offset of this record is found by adding

the offset of the RESTART_PAGE_HEADER to the restart_offset value found in

it.

struct {

__u64 current_lsn; Log file record. = 0x700000, 0x700808

__u16 log_clients; Number of log client records following

the restart_area. = 1

__u16 client_free_list; How many clients are free(?). If != 0xffff,

check that log_clients > client_free_list.

= 0xffff

__u16 client_in_use_list;How many clients are in use(?). If != 0xffff

check that log_clients > client_in_use_list.

= 0

__u16 flags; ??? = 0

__u32 seq_number_bits; ??? = 0x 2c or 0x2d

__u16 restart_area_length;Length of the restart area. Following

checks required if version matches.

Otherwise, skip them. restart_offset +

restart_area_length has to be <lt;=

system_page_size. Also, restart_area_length

has to be >= client_array_offset +

(log_clients * 0xa0). = 0xd0

__u16 client_array_offset;Offset from the start of this record to

the first client record if versions are

matched. The offset is otherwise assumed to

be (sizeof(RESTART_AREA) + 7) & ~7, i.e.

rounded up to first 8-byte boundary. Either

way, the offset to the client array has to be

aligned to an 8-byte boundary. Also,

restart_offset + offset to the client array

have to be <lt;= 510. Also, the offset to the

client array + (log_clients * 0xa0) have to

be <lt;= SystemPageSize. = 0x30

__u64 file_size; Byte size of the log file. If the

restart_offset + the offset of the file_size

are > 510 then corruption has occured. This

is the very first check when starting with

the restart_area as if it fails it means

that some of the above values will be

corrupted by the multi sector transfer

protection! If the structure is deprotected

then these checks are futile of course.

Calculate the file_size bits and check that

seq_number_bits == 0x43 - file_size bits.

= 0x400000

__u32 last_lsn_data_length;??? = 0, 0x40

__u16 record_length; Byte size of this record. If the version

matches then check that the value of

record_length is a multiple of 8, i.e.

(record_length + 7) & ~7 == record_length.

= 0x30

__u16 log_page_data_offset;??? = 0x40

} RESTART_AREA;

Log file client record. Starts at 0x58 even though AFAIU the above it should

start at 0x60. Something fishy is going on. /-:

struct {

__u64 oldest_lsn; Oldest log file sequence number for this

client record. = 0xbd16951d

__u64 client_restart_lsn;??? = 0x700000, 0x700827, 0x700d07

__u16 prev_client; ??? = 0x808, 0xd07, 0xd5d

__u16 next_client; ??? = 0x70

__u16 seq_number; ??? = 0, 4 size uncertain, Regis calls this

"volume clear flag" and gives a size of one

byte.

__u16 client_name; ??? = empty string??? size uncertain

} RESTART_CLIENT;

NOTE: Above client record is followed by 0xffffffff probably to indicate

the end of the restart area.

Then there are 8 bytes = 0, then one __u32 = 8, followed by the Unicode

string "NTFS" and then zeroes till the end of the page.

Is this important at all?

Log page record page header. Each log page begins with this header and is

followed by several LOG_RECORD structures.

struct {

NTFS_RECORD; The magic is "RCRD".

union {

__u64 last_lsn;

__u32 file_offset;

} copy;

__u32 flags;

__u16 page_count;

__u16 page_position;

union {

struct {

__u64 next_record_offset;

__u64 last_end_lsn;

} packed;

} header;

} RECORD_PAGE_HEADER;

Possible flags for log records.

enum {

LOG_RECORD_MULTI_PAGE = 1, ???

LOG_RECORD_SIZE_PLACE_HOLDER = 0xffff,

This has nothing to do with the log record. It is only so

gcc knows to make the flags 16-bit.

} LOG_RECORD_FLAGS;

Log record header.

struct {

__u64 this_lsn;

__u64 client_previous_lsn;

__u64 client_undo_next_lsn;

__u32 client_data_length;

struct {

__u16 seq_number;

__u16 client_index;

} client_id;

__u32 record_type;

__u32 transaction_id;

LOG_RECORD_FLAGS flags;

__u16 reserved_or_alignment[3];

Now are at ofs 0x30 into struct.

__u16 redo_operation;

__u16 undo_operation;

__u16 redo_offset;

__u16 redo_length;

__u16 undo_offset;

__u16 undo_length;

__u16 target_attribute;

__u16 lcns_to_follow; Number of lcn_list entries following this entry.

__u16 record_offset;

__u16 attribute_offset;

__u32 alignment_or_reserved;

__u32 target_vcn;

__u32 alignment_or_reserved1;

struct { Only present if lcns_to_follow is not 0.

__u32 lcn;

__u32 alignment_or_reserved;

} lcn_list[0];

} LOG_RECORD;

The restart area (supposedly) has a pointer into the log area, such as

the first and last log records written and the last checkpoint record

written. If the restart area is screwed, recovery will be very hard -

therefore you have two copies of the restart areas.

Individual log records are identified by logical sequence numbers

(LSNs). The log area wraps around, but the LSNs don't (at least not

anytime soon), so they are used for identifying log records instead of

the offset in the log file.

Any modification of meta data (such as updating the time stamp that

the file system was opened) will result in log file actions, which in

turn result in restart area changes. It might well be that the dirty

bit is implicit rather than explicit: The file system is clean if the

last log record says that there are no pending transactions.

2004.04.09
感谢：特别感谢开放源代码项目 Linux-NTFS Project 众多的 Linux 爱好者们，正因为他们多年来的不懈努力才使得 NTFS 文件系统的面纱被慢慢的揭开，并且通过开放源代码的威力让更多的编程爱好者在本文档的基础上编写了丰富的开源数据恢复及系统恢复等灾难拯救项目，你可以通过以下网址访问本项目位于 sourceforge.net 的原英文站点（http://linux-ntfs.sourceforge.net）
此版中文译本翻译、校正、注释并首发于时代http://www.getmydata.cn

转载请保留以上文字及连接，谢谢！