79 	 * first checkpoint it is written to. Hence if it is different to the  in xlog_item_in_current_chkpt()
80 	 * current sequence, we're in a new checkpoint.  in xlog_item_in_current_chkpt()
196  * initialise the first CIL checkpoint context.
407 	 * tell in future commits whether this is the first checkpoint  in xfs_cil_prepare_item()
538  * consumed by the item. Add the space to the checkpoint ticket and calculate
540  * as well. Remove the amount of space we added to the checkpoint ticket from
562 	 * We can do this safely because the context can't checkpoint until we  in xlog_cil_insert_items()
588 	 * We need to take the CIL checkpoint unit reservation on the first  in xlog_cil_insert_items()
714  * Take the checkpoint's log vector chain of items and insert the attached log
718  * The AIL tracks log items via the start record LSN of the checkpoint,
720  * checkpoints, and so the start record of checkpoint N+1 can be
721  * written before the commit record of checkpoint N. i.e:
728  * the items of that checkpoint are written back, because then the
732  * Hence when all the log items in checkpoint N are written back, the
734  * of checkpoint N+1.
737  * a CIL checkpoint commit has failed. In this case, all the items in the
738  * checkpoint have already gone through iop_committed and iop_committing, which
739  * means that checkpoint commit abort handling is treated exactly the same as an
766 	 * checkpoint. As iclogs are always completed in order, this should  in xlog_cil_ail_insert()
770 	 * space that this checkpoint has already consumed.  We call  in xlog_cil_ail_insert()
941 * contain the start record for the checkpoint. Otherwise this write contains
942 * the commit record for the checkpoint.
1010  * Ensure that the order of log writes follows checkpoint sequence order. This
1088  * Write out the commit record of a checkpoint transaction to close off a
1138  * Build a checkpoint transaction header to begin the journal transaction.  We
1390 	 * For example, if we get an EFI in one checkpoint and the EFD in the  in xlog_cil_push_work()
1391 	 * next (e.g. due to log forces), we do not want the checkpoint with  in xlog_cil_push_work()
1392 	 * the EFD to be committed before the checkpoint with the EFI.  Hence  in xlog_cil_push_work()
1394 	 * that: a) the checkpoint callbacks are attached to the iclogs in the  in xlog_cil_push_work()
1421 	 * Build a checkpoint transaction header and write it to the log to  in xlog_cil_push_work()
1448 	 * releasing the commit_iclog (i.e. checkpoint has been completed and  in xlog_cil_push_work()
1455 	 * If the checkpoint spans multiple iclogs, wait for all previous iclogs  in xlog_cil_push_work()
1483 		 * checkpoint is correctly preserved down to stable storage.  in xlog_cil_push_work()
1540  * the log. The limit really is that a checkpoint can't be more than half the
1541  * log (the current checkpoint is not allowed to overwrite the previous
1542  * checkpoint), but commit latency and memory usage limit this to a smaller
1621  * checkpoint is fully flushed out of the iclogs when we finish the push. If we
1687  * committed in the current (same) CIL checkpoint, we don't need to write either
1689  * journalled atomically within this checkpoint. As we cannot remove items from
1728  * transaction to the checkpoint context so we carry the busy extents through
1729  * to checkpoint completion, and then unlock all the items in the transaction.
1774 	 * to disk. If we don't, then the CIL checkpoint can race with us and  in xlog_cil_commit()
1775 	 * we can run checkpoint completion before we've updated and unlocked  in xlog_cil_commit()
1807 	 * If the CIL is empty, make sure that any previous checkpoint that may  in xlog_cil_flush()