Lines Matching full:fast
8 * Ext4 fast commits routines.
16 * Ext4 Fast Commits
19 * Ext4 fast commits implement fine grained journalling for Ext4.
21 * Fast commits are organized as a log of tag-length-value (TLV) structs. (See
24 * don't have replay code, fast commit falls back to full commits.
25 * Fast commits record delta in one of the following three categories.
46 * With fast commits, we maintain all the directory entry operations in the
49 * that need to be committed during a fast commit in another in memory queue of
55 * [4] Commit all the directory entry updates in the fast commit space
62 * update. If such an ongoing update is present, fast commit waits for it to
66 * Fast Commit Ineligibility
69 * Not all operations are supported by fast commits today (e.g extended
70 * attributes). Fast commit ineligibility is marked by calling
71 * ext4_fc_mark_ineligible(): This makes next fast commit operation to fall back
76 * In order to guarantee atomicity during the commit operation, fast commit
77 * uses "EXT4_FC_TAG_TAIL" tag that marks a fast commit as complete. Tail
79 * this fast commit should be applied. Recovery code replays fast commit
80 * logs only if there's at least 1 valid tail present. For every fast commit
82 * in the fast commit space. Here's an example:
90 * The fast commit space at the end of above operations would look like this:
92 * |<--- Fast Commit 1 --->|<--- Fast Commit 2 ---->|
96 * Fast Commit Replay Idempotence
99 * Fast commits tags are idempotent in nature provided the recovery code follows
105 * was associated with inode 10. During fast commit, instead of storing this
114 * system. This is what guarantees idempotence of fast commit replay.
116 * Let's take an example of a procedure that is not idempotent and see how fast
128 * the procedure fast commits store the outcome of each procedure. Thus the fast
143 * idempotent outcomes, fast commits ensured idempotence during the replay.
148 * 0) Fast commit replay path hardening: Fast commit replay code should use
150 * path are atomic. With that if we crash during fast commit replay, after
151 * trying to do recovery again, we will find a file system where fast commit
153 * with that, fast commit replay code should ensure that the "FC_REPLAY"
155 * the crash, fast commit recovery code can look at that flag and perform
156 * fast commit recovery even if that area is invalidated by later full
159 * 1) Fast commit's commit path locks the entire file system during fast
239 * Inform Ext4's fast about start of an inode update
243 * fast commit on the inode in question.
267 * Stop inode update and wake up waiting fast commits if any.
281 * Remove inode from fast commit list. If the inode is being committed
334 * Mark file system as fast commit ineligible, and record latest
364 * Generic fast commit tracking function. If this is the first time this we are
365 * called after a full commit, we initialize fast commit fields and then call
371 * If enqueue is set, this function enqueues the inode in fast commit list.
679 * Allocate len bytes on a fast commit buffer.
681 * During the commit time this function is used to manage fast commit
682 * block space. We don't split a fast commit log onto different
746 * Complete a fast commit by writing tail tag.
748 * Writing tail tag marks the end of a fast commit. In order to guarantee
842 * Writes inode in the fast commit space under TLV with tag @tag.
960 /* Submit data for all the fast commit inodes */
994 /* Wait for completion of data for all the fast commit inodes */
1105 * flush before we start writing fast commit blocks. in ext4_fc_perform_commit()
1113 * Add a head tag only if this is the first fast commit in ext4_fc_perform_commit()
1161 ext4_debug("Fast commit ended with status = %d for tid %u", in ext4_fc_update_stats()
1184 * The main commit entry point. Performs a fast commit for transaction
1185 * commit_tid if needed. If it's not possible to perform a fast commit
1227 * if we are fast commit ineligible. in ext4_fc_commit()
1263 * Fast commit cleanup routine. This is called after every fast commit and
1674 * Record physical disk regions which are in use as per fast commit area,
1793 * map to new physical blocks during a fast commit. in ext4_fc_replay_add_range()
2015 * - Make sure the fast commit area has valid tags for replay
2245 * We set replay callback even if fast commit disabled because we may in ext4_fc_init()
2246 * could still have fast commit blocks that need to be replayed even if in ext4_fc_init()
2247 * fast commit has now been turned off. in ext4_fc_init()