Lines Matching full:transaction

13 themselves with the general concepts of how transaction processing in XFS works.
16 transaction reservations are structured and accounted, and then move into how we
59 transactions. Permanent transaction reservations can take reservations that span
68 In the code, a one-shot transaction pattern looks somewhat like this::
72 	<join item to transaction>
76 As items are modified in the transaction, the dirty regions in those items are
77 tracked via the transaction handle.  Once the transaction is committed, all
79 space that was taken at the transaction allocation time.
81 In contrast, a permanent transaction is made up of multiple linked individual
97 While this might look similar to a one-shot transaction, there is an important
112 transaction does not form an atomic change in the journal. While each
139 ensuring that a long running permanent transaction is fully committed once it is
140 complete, we can explicitly tag a transaction as synchronous. This will trigger
150 Transaction Reservations
156 journal. This is achieved by the transaction reservations that are made when
157 a transaction is first allocated. For permanent transactions, these reservations
158 are maintained as part of the transaction rolling mechanism.
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
178 for the transaction that is calculated at mount time. We must guarantee that the
179 log has this much space available before the transaction is allowed to proceed
184 required for the transaction to proceed. For permanent transactions, however, we
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
191 know from the implementation of the permanent transactions how many transaction
197 transaction, we might set the reservation log count to a value of 2 to indicate
198 that the common/fast path transaction will commit two linked transactions in a
199 chain. Each time a permanent transaction rolls, it consumes an entire unit
202 Hence when the permanent transaction is first allocated, the log space
205 means we can roll the transaction multiple times before we have to re-reserve
206 log space when we roll the transaction. This ensures that the common
209 If the log count for a permanent transaction reaches zero, then it needs to
239 The reserve grant head is used to accurately account for exact transaction
245 mechanism ensures no transaction is starved of resources when log space
255 These differences when a permanent transaction is rolled and the internal "log
258 the next transaction in the sequeunce, but we have none remaining. We cannot
259 sleep during the transaction commit process waiting for new log space to become
263 then wake up transaction commit in progress.
285 	locked across each transaction they roll in the chain.
287 "Re-logging" the locked items on every transaction roll ensures that the items
288 attached to the transaction chain being rolled are always relocated to the
311 existing changes in the new transaction that is written to the log.
316 transaction::
318 	Transaction		Contents	LSN
327 In other words, each time an object is relogged, the new transaction contains
333 of each subsequent transaction, and it's the technique that allows us to
336 A typical example of a rolling transaction is the removal of extents from an
337 inode which can only be done at a rate of two extents per transaction because
338 of reservation size limitations. Hence a rolling extent removal transaction
349 dirtier as they get relogged, so each subsequent transaction is writing more
358 transaction throughput.
360 The limitation on asynchronous transaction throughput is the number and size of
396 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
411 words, instead of there only being a maximum of 2MB of transaction changes not
440 	6. No performance regressions for synchronous transaction workloads.
456 running. For example, a transaction has object A locked and modified, but needs
457 the delayed logging tracking lock to commit the transaction. However, the
467 transaction commit while the item is locked in the transaction. Instead of
475 rewriting can all be done while the object is locked during transaction commit,
539 exist once the object has been included in a transaction.
548 transaction.
560 in transaction commit order, so when an object is relogged it is removed from
574 need to be written as an atomic transaction. The need for all the objects to be
575 written as an atomic transaction comes from the requirements of relogging and
576 log replay - all the changes in all the objects in a given transaction must
578 a transaction is not replayed because it is not complete in the log, then
582 transaction. Fortunately, the XFS log code has no fixed limit on the size of a
583 transaction, nor does the log replay code. The only fundamental limit is that
584 the transaction cannot be larger than just under half the size of the log.  The
586 be at least one complete transaction in the log at any given time. If a
587 transaction is larger than half the log, then there is the possibility that a
588 crash during the write of a such a transaction could partially overwrite the
589 only complete previous transaction in the log. This will result in a recovery
593 Apart from this size requirement, a checkpoint transaction looks no different
594 to any other transaction - it contains a transaction header, a series of
596 perspective, the checkpoint transaction is also no different - just a lot
598 might need to tune the recovery transaction object hash size.
600 Because the checkpoint is just another transaction and all the changes to log
604 transaction. The current log write code enables us to do this easily with the
605 way it separates the writing of the transaction contents (the log vectors) from
606 the transaction commit record, but tracking this requires us to have a
612 at the same time a checkpoint transaction is started. That is, when we remove
621 workloads, just like the existing transaction commit code does. This, however,
625 To ensure that we can be writing an item into a checkpoint transaction at
626 the same time another transaction modifies the item and inserts the log item
627 into the new CIL, then checkpoint transaction commit code cannot use log items
628 to store the list of log vectors that need to be written into the transaction.
685 run transaction committed processing for the log items (i.e. insert into AIL
698 vectors in one checkpoint transaction. I'd guess this is a "measure and
705 One of the key aspects of the XFS transaction subsystem is that it tags
706 committed transactions with the log sequence number of the transaction commit.
708 future operations that cannot be completed until that transaction is fully
711 force can be issued to force the dependent transaction to disk immediately.
714 transaction. This LSN comes directly from the log buffer the transaction is
715 written into. While this works just fine for the existing transaction
728 Then, instead of assigning a log buffer LSN to the transaction commit LSN
762 transactions to remain untouched (i.e. commit an asynchronous transaction, then
763 force the log at the LSN of that transaction) and so the higher level code
769 The big issue for a checkpoint transaction is the log space reservation for the
770 transaction. We don't know how big a checkpoint transaction is going to be
776 A typical transaction reserves enough space in the log for the worst case space
777 usage of the transaction. The reservation accounts for log record headers,
778 transaction and region headers, headers for split regions, buffer tail padding,
780 transaction. While some of this is fixed overhead, much of it is dependent on
781 the size of the transaction and the number of regions being logged (the number
782 of log vectors in the transaction).
798 reservation does it cover? We account for space used by the transaction
814 the write reservation (the actual space available to the transaction) after
815 every checkpoint transaction completion. Unfortunately, if this space is not
828 result of a transaction commit inserting a new memory buffer into the CIL, then
829 the difference in space required is removed from the transaction that causes
835 Hence we can grow the checkpoint transaction reservation dynamically as items
842 of the reservation against the maximum allowed transaction size. If we reach
847 transaction commit code.
849 If the transaction subsystem goes idle while we still have items in the CIL,
851 force will push the CIL to disk, and if the transaction subsystem stays idle,
861 Currently log items are pinned during transaction commit while the items are
864 that items get pinned once for every transaction that is committed to the log
866 for every outstanding transaction they were dirtied in. When each of these
870 as there is a 1:1 relationship with transaction commit and log item completion.
872 For delayed logging, however, we have an asymmetric transaction commit to
875 That is, we now have a many-to-one relationship between transaction commit and
877 log items becomes unbalanced if we retain the "pin on transaction commit, unpin
878 on transaction completion" model.
884 the CIL during a transaction commit, then we do not pin it again. Because there
902 A fundamental requirement for the CIL is that accesses through transaction
903 commits must scale to many concurrent commits. The current transaction commit
905 processors at once. The current transaction code does not go any faster than if
908 As a result, the delayed logging transaction commit code needs to be designed
912 	1. Locking out new transaction commits while flushing the CIL
916 Looking at the transaction commit and CIL flushing interactions, it is clear
923 The amount of time a transaction commit needs to hold out a flush is a
929 the transaction commit side.
931 Because of the number of potential transaction commit side holders, the lock
938 transaction commit or CIL flush side sleeps with the lock held.
941 compared to transaction commit for asynchronous transaction workloads - only
943 transaction commit concurrency due to cache line bouncing of the lock on the
946 The second serialisation point is on the transaction commit side where items
952 hold time once per transaction I think that contention is unlikely.
983 	1. Transaction allocate
984 	2. Transaction reserve
986 	4. Join item to transaction
990 		Attach log item to transaction
993 	6. Transaction commit
996 		Write commit LSN into transaction
998 		Attach transaction to log buffer
1003 	7. Transaction completion
1028 	1. Transaction allocate
1029 	2. Transaction reserve
1031 	4. Join item to transaction
1035 		Attach log item to transaction
1038 	6. Transaction commit
1043 		Write CIL context sequence into transaction