8  * Ext4 fast commits routines.
17  * Ext4 Fast Commits
20  * Ext4 fast commits implement fine grained journalling for Ext4.
22  * Fast commits are organized as a log of tag-length-value (TLV) structs. (See
25  * don't have replay code, fast commit falls back to full commits.
26  * Fast commits record delta in one of the following three categories.
47  * With fast commits, we maintain all the directory entry operations in the
50  * that need to be committed during a fast commit in another in memory queue of
60  * [4] Mark all the fast commit eligible inodes as undergoing fast commit
65  *     will block until those inodes have finished the fast commit.
66  * [6] Commit all the directory entry updates in the fast commit space.
67  * [7] Commit all the changed inodes in the fast commit space and clear
75  * Fast Commit Ineligibility
78  * Not all operations are supported by fast commits today (e.g extended
79  * attributes). Fast commit ineligibility is marked by calling
80  * ext4_fc_mark_ineligible(): This makes next fast commit operation to fall back
85  * In order to guarantee atomicity during the commit operation, fast commit
86  * uses "EXT4_FC_TAG_TAIL" tag that marks a fast commit as complete. Tail
88  * this fast commit should be applied. Recovery code replays fast commit
89  * logs only if there's at least 1 valid tail present. For every fast commit
91  * in the fast commit space. Here's an example:
99  * The fast commit space at the end of above operations would look like this:
101  *             |<---  Fast Commit 1   --->|<---      Fast Commit 2     ---->|
105  * Fast Commit Replay Idempotence
108  * Fast commits tags are idempotent in nature provided the recovery code follows
114  * was associated with inode 10. During fast commit, instead of storing this
123  * system. This is what guarantees idempotence of fast commit replay.
125  * Let's take an example of a procedure that is not idempotent and see how fast
137  * the procedure fast commits store the outcome of each procedure. Thus the fast
152  * idempotent outcomes, fast commits ensured idempotence during the replay.
156  * sbi->s_fc_lock protects the fast commit inodes queue and the fast commit
157  * dentry queue. ei->i_fc_lock protects the fast commit related info in a given
164  * 0) Fast commit replay path hardening: Fast commit replay code should use
166  *    path are atomic. With that if we crash during fast commit replay, after
167  *    trying to do recovery again, we will find a file system where fast commit
169  *    with that, fast commit replay code should ensure that the "FC_REPLAY"
171  *    the crash, fast commit recovery code can look at that flag and perform
172  *    fast commit recovery even if that area is invalidated by later full
228  * Remove inode from fast commit list. If the inode is being committed
249 	 * handle open, there is no need for us to wait here even if a fast  in ext4_fc_del()
259 	 * file system as fast commit ineligible anyway. So, even in that case,  in ext4_fc_del()
308  * Mark file system as fast commit ineligible, and record latest
343  * Generic fast commit tracking function. If this is the first time this we are
344  * called after a full commit, we initialize fast commit fields and then call
350  * If enqueue is set, this function enqueues the inode in fast commit list.
596 	 * by fast or full commit as long as the handle is open.  in ext4_fc_track_inode()
683  * Allocate len bytes on a fast commit buffer.
685  * During the commit time this function is used to manage fast commit
686  * block space. We don't split a fast commit log onto different
750  * Complete a fast commit by writing tail tag.
752  * Writing tail tag marks the end of a fast commit. In order to guarantee
846  * Writes inode in the fast commit space under TLV with tag @tag.
1114 	 * issue a cache flush before we start writing fast commit blocks.  in ext4_fc_perform_commit()
1120 	/* Step 6: Write fast commit blocks to disk. */  in ext4_fc_perform_commit()
1123 		 * Step 6.1: Add a head tag only if this is the first fast  in ext4_fc_perform_commit()
1155 	/* Step 6.4: Finally write tail tag to conclude this fast commit. */  in ext4_fc_perform_commit()
1169 	ext4_debug("Fast commit ended with status = %d for tid %u",  in ext4_fc_update_stats()
1192  * The main commit entry point. Performs a fast commit for transaction
1193  * commit_tid if needed. If it's not possible to perform a fast commit
1237 	 * if we are fast commit ineligible.  in ext4_fc_commit()
1245 	 * Now that we know that this thread is going to do a fast commit,  in ext4_fc_commit()
1284  * Fast commit cleanup routine. This is called after every fast commit and
1710  * Record physical disk regions which are in use as per fast commit area,
1828 			 * map to new physical blocks during a fast commit.  in ext4_fc_replay_add_range()
2054  * - Make sure the fast commit area has valid tags for replay
2284 	 * We set replay callback even if fast commit disabled because we may  in ext4_fc_init()
2285 	 * could still have fast commit blocks that need to be replayed even if  in ext4_fc_init()
2286 	 * fast commit has now been turned off.  in ext4_fc_init()