Lines Matching refs:journal
6 Introduced in ext3, the ext4 filesystem employs a journal to protect the
12 committed is also written to the journal. At some later point in time,
13 the journal code writes the transactions to their final locations on
16 crash during the second slow write, the journal can be replayed all the
18 gets written through the journal to the disk. The effect of this is to
23 through the journal. This means that file data blocks are /not/
26 option to control journal behavior. If ``data=journal``, all data and
27 metadata are written to disk through the journal. This is slower but
29 disk before the metadata are written to disk through the journal.
31 The journal inode is typically inode 8. The first 68 bytes of the
32 journal inode are replicated in the ext4 superblock. The journal itself
42 The maximum size of a journal embedded in an ext4 filesystem is 2^32
48 Generally speaking, the journal has this format:
70 Optionally, an ext4 filesystem can be created with an external journal
71 device (as opposed to an internal journal, which uses a reserved inode).
73 zero and ``s_journal_uuid`` should be set. On the journal device there
75 The journal superblock will be in the next full block after the
97 Every block in the journal starts with a common 12-byte header
124 The journal block type can be any one of:
134 written through the journal during a transaction.
144 journal to skip writing blocks that were subsequently rewritten.
149 The super block for the journal is much simpler as compared to ext4's.
150 The key data kept within are size of the journal, and where to find the
153 The journal superblock is recorded as ``struct journal_superblock_s``,
167 - Static information describing the journal.
169 - journal\_header\_t (12 bytes)
179 - Total number of blocks in this journal.
196 being zero does not imply that the journal is clean!
220 - 128-bit uuid for journal. This is compared against the copy in the ext4
225 - Number of file systems sharing this journal.
233 - Limit of journal blocks per transaction. (Not used?)
241 - Checksum algorithm used for the journal. See jbd2_checksum_type_ for
264 The journal compat features are any combination of the following:
278 The journal incompat features are any combination of the following:
294 - This journal uses v2 of the checksum on-disk format. Each journal
297 journal. (JBD2\_FEATURE\_INCOMPAT\_CSUM\_V2)
299 - This journal uses v3 of the checksum on-disk format. This is the same as
300 v2, but the journal block tag size is fixed regardless of the size of
326 The descriptor block contains an array of journal block tags that
328 journal. Descriptor blocks are open-coded instead of being completely
341 - journal\_header\_t
345 - struct journal\_block\_tag\_s
351 journal feature and block tag flags are set.
353 If JBD2\_FEATURE\_INCOMPAT\_CSUM\_V3 is set, the journal block tag is
384 - Checksum of the journal UUID, the sequence number, and the data block.
400 The journal tag flags are any combination of the following:
419 If JBD2\_FEATURE\_INCOMPAT\_CSUM\_V3 is NOT set, the journal block tag
439 - Checksum of the journal UUID, the sequence number, and the data block.
484 - Checksum of the journal UUID + the descriptor block, with this field set
490 In general, the data blocks being written to disk through the journal
491 are written verbatim into the journal file after the descriptor block.
503 journal replay after the file block was written to disk will cause
506 **NOTE**: This mechanism is NOT used to express “this journal block is
507 superseded by this other journal block”, as the author (djwong)
524 - journal\_header\_t
556 - Checksum of the journal UUID + revocation block
562 completely written to the journal. Once this commit block reaches the
563 journal, the data stored with this transaction can be written to their
578 - journal\_header\_s
599 are set, the first ``__be32`` is the checksum of the journal UUID and