« back to all changes in this revision
Viewing changes to files/logfile.html
- browse files at revision 1
- compare with another revision
- download diff
- download tarball
- view history from revision 1
- Committer: Bazaar Package Importer
- Author(s): David Martínez Moreno
- Date: 2002-01-12 03:35:17 UTC
- Revision ID: james.westby@ubuntu.com-20020112033517-tspnkaz5z9o0y6b2
Tags: upstream-0.4
Import upstream version 0.4
- files added:
- attributes
- concepts
- files
- help
- style
added
removed
files/logfile.html
1
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2
<!-- http://linux-ntfs.sourceforge.net/ntfs/files/logfile.html -->
3
4
<html lang="en">
5
<head>
6
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
7
<meta name="description" content="NTFS Documentation">
8
<link rel="stylesheet" type="text/css" href="../style/ntfsdoc.css">
9
<link rel="start" type="text/html" href="../index.html" title="NTFS Documentation">
10
<title>$LogFile (2) - File - NTFS Documentation</title>
11
</head>
12
13
<body>
14
<table border="0" class="toolbar" summary="" cellspacing="0">
15
<tr>
16
<td class="toolbar"><a accesskey="1" class="toolbar" href="../index.html">Home</a></td>
17
<td class="toolbar"> </td>
18
<td class="toolbar"><a accesskey="2" class="toolbar" href="../files/index.html">Files</a></td>
19
<td class="toolbar"> </td>
20
<td class="toolbar"><a accesskey="3" class="toolbar" href="../attributes/index.html">Attributes</a></td>
21
<td class="toolbar"> </td>
22
<td class="toolbar"><a accesskey="4" class="toolbar" href="../concepts/index.html">Concepts</a></td>
23
<td class="toolbar"> </td>
24
<td class="toolbar"><a accesskey="5" class="toolbar" href="../help/glossary.html">Glossary</a></td>
25
<td class="toolbar"> </td>
26
<td class="toolbar"><a accesskey="6" class="toolbar" href="../help/index.html">Help</a></td>
27
</tr>
28
</table>
29
30
<h1>File - $LogFile (2)</h1>
31
<a class="prevnext" accesskey="," href="mftmirr.html">Previous</a>
32
<a class="prevnext" accesskey="." href="volume.html">Next</a>
33
34
<h2>Overview</h2>
35
36
<h2><a class="heading" href="../attributes/index.html">Attributes</a></h2>
37
38
<table border="1" summary="" cellspacing="0">
39
<tr>
40
<th class="numeric">Type</th>
41
<th>Description</th>
42
<th>Name</th>
43
</tr>
44
<tr>
45
<td class="numeric"><a class="numeric" href="../attributes/standard_information.html">0x10</a></td>
46
<td><a href="../attributes/standard_information.html">$STANDARD_INFORMATION</a></td>
47
<td> </td>
48
</tr>
49
<tr>
50
<td class="numeric"><a class="numeric" href="../attributes/file_name.html">0x30</a></td>
51
<td><a href="../attributes/file_name.html">$FILE_NAME</a></td>
52
<td>$LogFile</td>
53
</tr>
54
<tr>
55
<td class="numeric"><a class="numeric" href="../attributes/data.html">0x80</a></td>
56
<td><a href="../attributes/data.html">$DATA</a></td>
57
<td>[Unnamed]</td>
58
</tr>
59
</table>
60
61
<h2>Layout of the File</h2>
62
<h3>Unnamed Data Stream</h3>
63
64
<p>
65
Little is known about the LogFile's structure.
66
</p>
67
68
<!--
69
<table border="1" summary="" cellspacing="0">
70
<tr>
71
<th></th>
72
</tr>
73
<tr>
74
<td></td>
75
</tr>
76
</table>
77
-->
78
79
<h2>Notes</h2>
80
81
<h3>Other Information</h3>
82
83
<p>
84
The logging area consists of a sequence of 4KB log records. Each
85
logrecord is structured as follows:
86
</p>
87
88
<pre>
89
offset(length) contents
90
0(4) Magic number 'RCRD'
91
1E(12) Fixup
92
</pre>
93
94
<p>
95
The logrecord supposedly contains a sequence of variable sized records. The
96
structuring of those is not clear. File 2 is $LogFile, which contains transaction
97
records to guarantee data integrity in case of a system failure. As pp. 37 describe,
98
it consists of 2 copies of the restart area, and the 'infinite' logging area.
99
</p>
100
101
<p>When you want to write a file on a storage unit, you have to update the file
102
itself plus some tables of the filesystem (say as an example the date of the file).
103
At this point, you need a transaction made of 2 operations (update the file itself,
104
update the date of the file).</p>
105
106
<p>If the transaction is realized, you are sure that your file is written on the
107
storage unit, and that the filesystem has been left in a defined state.</p>
108
109
<p>If the transaction is not realized (in case of e.g. power failure, or system
110
failure in general), the filesystem is in an undefined state. The only way for you to
111
put it back in a defined (and sane) state (this operation is called a roll-back) is
112
to log in a special file, the log file, which operations of the transaction have been
113
successfully completed.</p>
114
115
<p>At the first access to the disk after a system failure, the system read the log
116
file and rolls back all the operations to the beginning of the last transaction.</p>
117
118
<ul>
119
<li>When the system writes to the log file, the operation must be atomic and
120
immediate.</li>
121
122
<li>
123
You can put back your volume in sane state in a short time which is not related
124
to the size of your disk but only to the complexity of the transaction that
125
failed.
126
127
<p>Note: This operation is not performed by the Windows NT
128
chkdsk utility, but by the system: this normal and reliable
129
operation is a feature of NTFS.</p>
130
</li>
131
132
<li>If your hardware is reliable, you are sure that you always have access to all
133
the files of your volume, because it is consistent. But you can't restore eventual
134
data losses.</li>
135
</ul>
136
137
<pre>
138
Log file organization:
139
Two restart areas present in the first two pages (restart pages). When
140
the volume is unmounted they should be identical.
141
These are followed by log records organized in pages headed by a record
142
header going up to log file size. Not all pages contain log records when a
143
volume is first formatted, but as the volume ages, all records will be used.
144
When the log file fills up, the records at the beginning are purged (by
145
modifying the oldest_lsn to a higher value presumably) and writing begins
146
at the beginning of the file. Effectively, the log file is viewed as a
147
circular entity.
148
149
Log file restart page header (begins the restart area).
150
151
struct {
152
NTFS_RECORD; The magic is "RSTR".
153
__u64 chkdsk_lsn; The check disk log file sequence number for
154
this restart page. Only used when the
155
magic is changed to "CHKD". = 0
156
__u32 system_page_size; Byte size of system pages, has to be >= 512
157
and a power of 2. Use this to calculate the
158
required size of the usa and add this to the
159
ntfs.usa_offset value. Then verify that the
160
result is less than the value of the
161
restart_offset. = 0x1000
162
__u32 log_page_size; Byte size of log file records, has to be
163
>= 512 and a power of 2. = 0x1000
164
__u16 restart_offset; Byte offset from the start of the record to
165
the restart record. Value has to be aligned
166
to 8-byte boundary. = 0x30
167
__s16 minor_ver; Log file minor version. Only check if major
168
version is 1. (=1 but >=1 is treated the
169
same and <=0 is also ok)
170
__u16 major_ver; Log file major version (=1 but =0 is ok)
171
} RESTART_PAGE_HEADER;
172
173
Log file restart area record. The offset of this record is found by adding
174
the offset of the RESTART_PAGE_HEADER to the restart_offset value found in
175
it.
176
177
struct {
178
__u64 current_lsn; Log file record. = 0x700000, 0x700808
179
__u16 log_clients; Number of log client records following
180
the restart_area. = 1
181
__u16 client_free_list; How many clients are free(?). If != 0xffff,
182
check that log_clients > client_free_list.
183
= 0xffff
184
__u16 client_in_use_list;How many clients are in use(?). If != 0xffff
185
check that log_clients > client_in_use_list.
186
= 0
187
__u16 flags; ??? = 0
188
__u32 seq_number_bits; ??? = 0x2c or 0x2d
189
__u16 restart_area_length;Length of the restart area. Following
190
checks required if version matches.
191
Otherwise, skip them. restart_offset +
192
restart_area_length has to be <lt;=
193
system_page_size. Also, restart_area_length
194
has to be >= client_array_offset +
195
(log_clients * 0xa0). = 0xd0
196
__u16 client_array_offset;Offset from the start of this record to
197
the first client record if versions are
198
matched. The offset is otherwise assumed to
199
be (sizeof(RESTART_AREA) + 7) & ~7, i.e.
200
rounded up to first 8-byte boundary. Either
201
way, the offset to the client array has to be
202
aligned to an 8-byte boundary. Also,
203
restart_offset + offset to the client array
204
have to be <lt;= 510. Also, the offset to the
205
client array + (log_clients * 0xa0) have to
206
be <lt;= SystemPageSize. = 0x30
207
__u64 file_size; Byte size of the log file. If the
208
restart_offset + the offset of the file_size
209
are > 510 then corruption has occured. This
210
is the very first check when starting with
211
the restart_area as if it fails it means
212
that some of the above values will be
213
corrupted by the multi sector transfer
214
protection! If the structure is deprotected
215
then these checks are futile of course.
216
Calculate the file_size bits and check that
217
seq_number_bits == 0x43 - file_size bits.
218
= 0x400000
219
__u32 last_lsn_data_length;??? = 0, 0x40
220
__u16 record_length; Byte size of this record. If the version
221
matches then check that the value of
222
record_length is a multiple of 8, i.e.
223
(record_length + 7) & ~7 == record_length.
224
= 0x30
225
__u16 log_page_data_offset;??? = 0x40
226
} RESTART_AREA;
227
228
Log file client record. Starts at 0x58 even though AFAIU the above it should
229
start at 0x60. Something fishy is going on. /-:
230
231
struct {
232
__u64 oldest_lsn; Oldest log file sequence number for this
233
client record. = 0xbd16951d
234
__u64 client_restart_lsn;??? = 0x700000, 0x700827, 0x700d07
235
__u16 prev_client; ??? = 0x808, 0xd07, 0xd5d
236
__u16 next_client; ??? = 0x70
237
__u16 seq_number; ??? = 0, 4 size uncertain, Regis calls this
238
"volume clear flag" and gives a size of one
239
byte.
240
__u16 client_name; ??? = empty string??? size uncertain
241
} RESTART_CLIENT;
242
243
NOTE: Above client record is followed by 0xffffffff probably to indicate
244
the end of the restart area.
245
Then there are 8 bytes = 0, then one __u32 = 8, followed by the Unicode
246
string "NTFS" and then zeroes till the end of the page.
247
Is this important at all?
248
249
Log page record page header. Each log page begins with this header and is
250
followed by several LOG_RECORD structures.
251
252
struct {
253
NTFS_RECORD; The magic is "RCRD".
254
union {
255
__u64 last_lsn;
256
__u32 file_offset;
257
} copy;
258
__u32 flags;
259
__u16 page_count;
260
__u16 page_position;
261
union {
262
struct {
263
__u64 next_record_offset;
264
__u64 last_end_lsn;
265
} packed;
266
} header;
267
} RECORD_PAGE_HEADER;
268
269
Possible flags for log records.
270
271
enum {
272
LOG_RECORD_MULTI_PAGE = 1, ???
273
LOG_RECORD_SIZE_PLACE_HOLDER = 0xffff,
274
This has nothing to do with the log record. It is only so
275
gcc knows to make the flags 16-bit.
276
} LOG_RECORD_FLAGS;
277
278
Log record header.
279
280
struct {
281
__u64 this_lsn;
282
__u64 client_previous_lsn;
283
__u64 client_undo_next_lsn;
284
__u32 client_data_length;
285
struct {
286
__u16 seq_number;
287
__u16 client_index;
288
} client_id;
289
__u32 record_type;
290
__u32 transaction_id;
291
LOG_RECORD_FLAGS flags;
292
__u16 reserved_or_alignment[3];
293
Now are at ofs 0x30 into struct.
294
__u16 redo_operation;
295
__u16 undo_operation;
296
__u16 redo_offset;
297
__u16 redo_length;
298
__u16 undo_offset;
299
__u16 undo_length;
300
__u16 target_attribute;
301
__u16 lcns_to_follow; Number of lcn_list entries following this entry.
302
__u16 record_offset;
303
__u16 attribute_offset;
304
__u32 alignment_or_reserved;
305
__u32 target_vcn;
306
__u32 alignment_or_reserved1;
307
struct { Only present if lcns_to_follow is not 0.
308
__u32 lcn;
309
__u32 alignment_or_reserved;
310
} lcn_list[0];
311
} LOG_RECORD;
312
313
The restart area (supposedly) has a pointer into the log area, such as
314
the first and last log records written and the last checkpoint record
315
written. If the restart area is screwed, recovery will be very hard -
316
therefore you have two copies of the restart areas.
317
Individual log records are identified by logical sequence numbers
318
(LSNs). The log area wraps around, but the LSNs don't (at least not
319
anytime soon), so they are used for identifying log records instead of
320
the offset in the log file.
321
Any modification of meta data (such as updating the time stamp that
322
the file system was opened) will result in log file actions, which in
323
turn result in restart area changes. It might well be that the dirty
324
bit is implicit rather than explicit: The file system is clean if the
325
last log record says that there are no pending transactions.
326
</pre>
327
328
<br>
329
<a class="contact" href="http://linux-ntfs.sourceforge.net/ntfs/files/logfile.html">Online</a>
330
<!-- The two validators will only work if this page is visible on the web -->
331
<a class="contact" href="http://validator.w3.org/check/referer">Validate HTML</a>
332
<a class="contact" href="http://jigsaw.w3.org/css-validator/check/referer">Validate CSS</a>
333
<a class="contact" href="mailto:webmaster@flatcap.org">$Id: logfile.html,v 1.11 2001/07/11 16:31:45 flatcap Exp $</a>
334
</body>
335
</html>
336
Loggerhead is a web-based interface for Breezy
Version: 2.0.1