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.
323 - Journal has fast commit blocks. (JBD2_FEATURE_INCOMPAT_FAST_COMMIT)
634 Fast commits
637 Fast commit area is organized as a log of tag length values. Each TLV has
651 - Fast commit area header
653 - Stores the TID of the transaction after which these fast commits should
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
689 Fast Commit Replay Idempotence
692 Fast commits tags are idempotent in nature provided the recovery code follows
698 was associated with inode 10. During fast commit, instead of storing this
707 system. This is what guarantees idempotence of fast commit replay.
709 Let's take an example of a procedure that is not idempotent and see how fast
721 of storing the procedure fast commits store the outcome of each procedure. Thus
722 the fast commit log for above procedure would be as follows:
737 into a series of idempotent outcomes, fast commits ensured idempotence during