Lines Matching refs:commit

15 read-write-erases) before erasing the commit record. Should the system
17 way to the latest commit record, guaranteeing the atomicity of whatever
32 help reduce commit latency significantly. The default ``data=ordered``
33 mode works by logging metadata blocks to the journal. In fast commit
35 affected metadata in fast commit space that is shared with JBD2.
36 Once the fast commit area fills in or if fast commit is not possible
37 or if JBD2 commit timer goes off, Ext4 performs a traditional full commit.
38 A full commit invalidates all the fast commits that happened before
39 it and thus it makes the fast commit area empty for further fast
75 commit. If there is no commit record (or the checksums don't match), the
147      - Block commit record. This block signifies the completion of a
202      - First commit ID expected in log.
261      - Number of fast commit blocks in the journal.
323      - Journal has fast commit blocks. (JBD2_FEATURE_INCOMPAT_FAST_COMMIT)
583 The commit block is a sentry that indicates that a transaction has been
584 completely written to the journal. Once this commit block reaches the
588 The commit block is described by ``struct commit_header``, which is 32
622        the entire commit block, with this field zeroed. If
637 Fast commit area is organized as a log of tag length values. Each TLV has
651      - Fast commit area header
681      - Unused bytes in the fast commit area.
684      - Mark the end of a fast commit
686      - Stores the TID of the commit, CRC of the fast commit of which this tag
693 certain rules. The guiding principle that the commit path follows while
698 was associated with inode 10. During fast commit, instead of storing this
707 system. This is what guarantees idempotence of fast commit replay.
722 the fast commit log for above procedure would be as follows: