Lines Matching full:space

27 are atomic and recoverable. For reasons of space and time efficiency, the
40 The reason for these differences is to keep the amount of log space and CPU time
57 XFS has two types of high level transactions, defined by the type of log space
79 space that was taken at the transaction allocation time.
155 because it can't be written to the journal due to a lack of space in the
160 A transaction reservation provides a guarantee that there is physical log space
165 transaction, we have to reserve enough space to record a full leaf-to-root split
170 free space, which modifies the free space trees. That's two btrees.  Inserting
172 btree, which requires another allocation that can modify the free space trees
174 another btree which might require more space. And so on.  Hence the amount of
179 log has this much space available before the transaction is allowed to proceed
181 of log space half way through the write.
183 For one-shot transactions, a single unit space reservation is all that is
188 While a permanent transaction can get by with a single unit of space
190 transaction rolling mechanism to re-reserve space on every transaction roll. We
202 Hence when the permanent transaction is first allocated, the log space
206 log space when we roll the transaction. This ensures that the common
207 modifications we make only need to reserve log space once.
210 re-reserve physical space in the log. This is somewhat complex, and requires
211 an understanding of how the log accounts for space that has been reserved.
214 Log Space Accounting
223 available space in the log.
225 Log space accounting is done via a pair of constructs called "grant heads".  The
226 position of the grant heads is an absolute value, so the amount of space
228 grant head and the current log tail. That is, how much space can be
234 accounting of the space reservation and, as such, actually tracks byte offsets
237 tuple for the purposes of tracking reservation space.
244 forward it will wake them in order once sufficient space is available. This FIFO
245 mechanism ensures no transaction is starved of resources when log space
249 head contains an LSN and it tracks the physical space usage in the log. While
257 exhausted. At this point, we still require a log space reservation to continue
259 sleep during the transaction commit process waiting for new log space to become
262 enough free space in the log to fulfill all of the pending reservations and
266 reservation even if there is no reservation space currently available. That is,
267 we need to be able to *overcommit* the log reservation space. As has already
268 been detailed, we cannot overcommit physical log space. However, the reserve
269 grant head does not track physical space - it only accounts for the amount of
277 As a result, permanent transactions only "regrant" reservation space during
278 xfs_trans_commit() calls, while the physical log space reservation - tracked by
281 physical log space to be reserved from the write grant head, but only if one
292 move the tail of the log forwards to free up write grant space. Re-logging the
298 tail moving forwards and hence ensuring that write grant space is always
386 wasting space. When we are doing repeated operations on the same set of
387 objects, these "stale objects" can be over 90% of the space used in the log
766 Delayed Logging: Checkpoint Log Space Accounting
769 The big issue for a checkpoint transaction is the log space reservation for the
773 amount of log space required as we add items to the commit item list, but we
774 still need to reserve the space in the log for the checkpoint.
776 A typical transaction reserves enough space in the log for the worst case space
779 etc. as well as the actual space for all the changed metadata in the
793 space.  From this, it should be obvious that a static log space reservation is
798 reservation does it cover? We account for space used by the transaction
799 reservation by tracking the space currently used by the object in the CIL and
800 then calculating the increase or decrease in space used as the object is
805 problematic. Typically log record headers use at least 16KB of log space per
806 1MB of log space consumed (512 bytes per 32k) and the reservation needs to be
809 be able to reserve the space without sleeping.  For a 8MB checkpoint, we need a
810 reservation of around 150KB, which is a non-trivial amount of space.
813 permanent reservation on the space, but we still need to make sure we refresh
814 the write reservation (the actual space available to the transaction) after
815 every checkpoint transaction completion. Unfortunately, if this space is not
819 checkpoints to be able to free up log space (refer back to the description of
821 space available in the log if we are to use static reservations, and that is
825 The simpler way of doing this is tracking the entire log space used by the
827 space required by the log metadata. If this log metadata space changes as a
829 the difference in space required is removed from the transaction that causes
830 the change. Transactions at this level will *always* have enough space
832 maximal amount of log metadata space they require, and such a delta reservation
836 are added to the CIL and avoid the need for reserving and regranting log space
913 	2. Adding items to the CIL and updating item space accounting
919 the amount of space available in the log for their reservations. The practical