Lines Matching refs:reservation

58 reservation they take. These are known as "one shot" and "permanent"
63 The type and size of reservation must be matched to the modification taking
70 	tp = xfs_trans_alloc(<reservation>)
78 resources joined to it are released, along with the remaining unused reservation
84 	tp = xfs_trans_alloc(<reservation>)
160 A transaction reservation provides a guarantee that there is physical log space
162 modifications to objects and items. As such, the reservation needs to be large
177 This "worst case" calculation provides us with the static "unit reservation"
183 For one-shot transactions, a single unit space reservation is all that is
185 also have a "log count" that affects the size of the reservation that is to be
189 reservation, it is somewhat inefficient to do this as it requires the
197 transaction, we might set the reservation log count to a value of 2 to indicate
200 reservation.
203 reservation is increased from a single unit reservation to multiple unit
204 reservations. That multiple is defined by the reservation log count, and this
234 accounting of the space reservation and, as such, actually tracks byte offsets
237 tuple for the purposes of tracking reservation space.
257 exhausted. At this point, we still require a log space reservation to continue
265 To take a new reservation without sleeping requires us to be able to take a
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
277 As a result, permanent transactions only "regrant" reservation space during
278 xfs_trans_commit() calls, while the physical log space reservation - tracked by
290 pins the tail of the log when we sleep on the write reservation, then we will
293 locked items avoids this deadlock and guarantees that the log reservation we are
338 of reservation size limitations. Hence a rolling extent removal transaction
769 The big issue for a checkpoint transaction is the log space reservation for the
777 usage of the transaction. The reservation accounts for log record headers,
793 space.  From this, it should be obvious that a static log space reservation is
797 Further, if we are going to use a static reservation, which bit of the entire
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
801 relogged. This allows for a checkpoint reservation to only have to account for
804 However, even using a static reservation for just the log metadata is
806 1MB of log space consumed (512 bytes per 32k) and the reservation needs to be
808 reservation needs to be made before the checkpoint is started, and we need to
810 reservation of around 150KB, which is a non-trivial amount of space.
812 A static reservation needs to manipulate the log grant counters - we can take a
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
831 available in their reservation for this as they have already reserved the
832 maximal amount of log metadata space they require, and such a delta reservation
833 will always be less than or equal to the maximal amount in the reservation.
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
842 of the reservation against the maximum allowed transaction size. If we reach