filesystems/xfs/xfs-delayed-logging-design.rst

41 required to process objects being modified as small as possible and hence the
106 across the entire chain of transactions.  Hence while this series of rolling
119 there is no guarantee of how much of the operation reached stale storage. Hence
131 to stable storage when it returns. Hence when a system crashes, not all the
174 another btree which might require more space. And so on.  Hence the amount of
196 from an inode chunk that has free inodes in it.  Hence for an inode allocation
202 Hence when the permanent transaction is first allocated, the log space
222 bytes). Hence we can do realtively simple LSN based math to keep track of
235 into the log rather than basic blocks. Hence it technically isn't using LSNs to
270 reservations we currently have outstanding. Hence if the reserve head passes
298 tail moving forwards and hence ensuring that write grant space is always
338 of reservation size limitations. Hence a rolling extent removal transaction
344 Hence it can be seen that the relogging operation is fundamental to the correct
370 IO permanently. Hence the XFS journalling subsystem can be considered to be IO
396 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
413 being accumulated in memory. Hence the potential for loss of metadata on a
426 log is used effectively in many filesystems including ext3 and ext4. Hence
452 concurrent modification. Hence flushing the logical changes to the log would
479 Hence we avoid the need to lock items when we need to flush outstanding
523 Hence we need to keep the vector, but by attaching the memory buffer to it and
527 Hence we avoid needing a new on-disk format to handle items that have been
553 can we store state in any field that is protected by the AIL lock. Hence the
590 failure and an inconsistent filesystem and hence we must enforce the maximum
610 Hence a checkpoint has a context that tracks the state of the current
629 Hence log vectors need to be able to be chained together to allow them to be
717 written directly into the log buffers. Hence some other method of sequencing
820 rolling transactions for an example of this).  Hence we *must* always have
835 Hence we can grow the checkpoint transaction reservation dynamically as items
841 log. Hence as part of the reservation growing, we need to also check the size
865 buffers. Hence items that are relogged in the log buffers will have a pin count
896 (or not pinning, as the case may be). Hence we must hold the CIL flush/commit
1078 Hence delayed logging should not introduce any constraints on log item