fs/xfs/xfs_log_cil.c

53  * initialise the first CIL checkpoint context.
262 	 * tell in future commits whether this is the first checkpoint  in xfs_cil_prepare_item()
380  * consumed by the item. Add the space to the checkpoint ticket and calculate
382  * as well. Remove the amount of space we added to the checkpoint ticket from
401 	 * We can do this safely because the context can't checkpoint until we  in xlog_cil_insert_items()
419 	 * for the checkpoint. The context ticket is special - the unit  in xlog_cil_insert_items()
763 	 * For example, if we get an EFI in one checkpoint and the EFD in the  in xlog_cil_push_work()
764 	 * next (e.g. due to log forces), we do not want the checkpoint with  in xlog_cil_push_work()
765 	 * the EFD to be committed before the checkpoint with the EFI.  Hence  in xlog_cil_push_work()
767 	 * that: a) the checkpoint callbacks are attached to the iclogs in the  in xlog_cil_push_work()
787 	 * Build a checkpoint transaction header and write it to the log to  in xlog_cil_push_work()
814 	 * now that we've written the checkpoint into the log, strictly  in xlog_cil_push_work()
864 	 * now the checkpoint commit is complete and we've attached the  in xlog_cil_push_work()
892  * the log. The limit really is that a checkpoint can't be more than half the
893  * log (the current checkpoint is not allowed to overwrite the previous
894  * checkpoint), but commit latency and memory usage limit this to a smaller
1003  * transaction to the checkpoint context so we carry the busy extents through
1004  * to checkpoint completion, and then unlock all the items in the transaction.
1051 	 * to disk. If we don't, then the CIL checkpoint can race with us and  in xfs_log_commit_cil()
1052 	 * we can run checkpoint completion before we've updated and unlocked  in xfs_log_commit_cil()
1185 	 * first checkpoint it is written to. Hence if it is different to the  in xfs_log_item_in_current_chkpt()
1186 	 * current sequence, we're in a new checkpoint.  in xfs_log_item_in_current_chkpt()