Lines Matching full:fast
31 In case of ``data=ordered`` mode, Ext4 also supports fast commits which
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
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
261 - Number of fast commit blocks in the journal.
318 - Journal has fast commit blocks. (JBD2_FEATURE_INCOMPAT_FAST_COMMIT)
629 Fast commits
632 Fast commit area is organized as a log of tag length values. Each TLV has
646 - Fast commit area header
648 - Stores the TID of the transaction after which these fast commits should
676 - Unused bytes in the fast commit area.
679 - Mark the end of a fast commit
681 - Stores the TID of the commit, CRC of the fast commit of which this tag
684 Fast Commit Replay Idempotence
687 Fast commits tags are idempotent in nature provided the recovery code follows
693 was associated with inode 10. During fast commit, instead of storing this
702 system. This is what guarantees idempotence of fast commit replay.
704 Let's take an example of a procedure that is not idempotent and see how fast
716 of storing the procedure fast commits store the outcome of each procedure. Thus
717 the fast commit log for above procedure would be as follows:
732 into a series of idempotent outcomes, fast commits ensured idempotence during