Lines Matching refs:transaction

26 changes in the new transaction that is written to the log.
31 transaction::
42 In other words, each time an object is relogged, the new transaction contains
48 (increasing) LSN of each subsequent transaction - the LSN is effectively a
49 direct encoding of the location in the log of the transaction.
52 transactions.  These transaction are known as rolling transactions, and require
53 a special log reservation known as a permanent transaction reservation. A
54 typical example of a rolling transaction is the removal of extents from an
55 inode which can only be done at a rate of two extents per transaction because
56 of reservation size limitations. Hence a rolling extent removal transaction
67 dirtier as they get relogged, so each subsequent transaction is writing more
70 Another feature of the XFS transaction subsystem is that most transactions are
75 minimise the impact of the log IO on transaction throughput.
77 The limitation on asynchronous transaction throughput is the number and size of
113 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
128 words, instead of there only being a maximum of 2MB of transaction changes not
157 	6. No performance regressions for synchronous transaction workloads.
173 running. For example, a transaction has object A locked and modified, but needs
174 the delayed logging tracking lock to commit the transaction. However, the
184 transaction commit while the item is locked in the transaction. Instead of
192 rewriting can all be done while the object is locked during transaction commit,
256 exist once the object has been included in a transaction.
265 transaction.
277 in transaction commit order, so when an object is relogged it is removed from
291 need to be written as an atomic transaction. The need for all the objects to be
292 written as an atomic transaction comes from the requirements of relogging and
293 log replay - all the changes in all the objects in a given transaction must
295 a transaction is not replayed because it is not complete in the log, then
299 transaction. Fortunately, the XFS log code has no fixed limit on the size of a
300 transaction, nor does the log replay code. The only fundamental limit is that
301 the transaction cannot be larger than just under half the size of the log.  The
303 be at least one complete transaction in the log at any given time. If a
304 transaction is larger than half the log, then there is the possibility that a
305 crash during the write of a such a transaction could partially overwrite the
306 only complete previous transaction in the log. This will result in a recovery
310 Apart from this size requirement, a checkpoint transaction looks no different
311 to any other transaction - it contains a transaction header, a series of
313 perspective, the checkpoint transaction is also no different - just a lot
315 might need to tune the recovery transaction object hash size.
317 Because the checkpoint is just another transaction and all the changes to log
321 transaction. The current log write code enables us to do this easily with the
322 way it separates the writing of the transaction contents (the log vectors) from
323 the transaction commit record, but tracking this requires us to have a
329 at the same time a checkpoint transaction is started. That is, when we remove
338 workloads, just like the existing transaction commit code does. This, however,
342 To ensure that we can be writing an item into a checkpoint transaction at
343 the same time another transaction modifies the item and inserts the log item
344 into the new CIL, then checkpoint transaction commit code cannot use log items
345 to store the list of log vectors that need to be written into the transaction.
402 run transaction committed processing for the log items (i.e. insert into AIL
415 vectors in one checkpoint transaction. I'd guess this is a "measure and
422 One of the key aspects of the XFS transaction subsystem is that it tags
423 committed transactions with the log sequence number of the transaction commit.
425 future operations that cannot be completed until that transaction is fully
428 force can be issued to force the dependent transaction to disk immediately.
431 transaction. This LSN comes directly from the log buffer the transaction is
432 written into. While this works just fine for the existing transaction
445 Then, instead of assigning a log buffer LSN to the transaction commit LSN
479 transactions to remain untouched (i.e. commit an asynchronous transaction, then
480 force the log at the LSN of that transaction) and so the higher level code
486 The big issue for a checkpoint transaction is the log space reservation for the
487 transaction. We don't know how big a checkpoint transaction is going to be
493 A typical transaction reserves enough space in the log for the worst case space
494 usage of the transaction. The reservation accounts for log record headers,
495 transaction and region headers, headers for split regions, buffer tail padding,
497 transaction. While some of this is fixed overhead, much of it is dependent on
498 the size of the transaction and the number of regions being logged (the number
499 of log vectors in the transaction).
515 reservation does it cover? We account for space used by the transaction
531 the write reservation (the actual space available to the transaction) after
532 every checkpoint transaction completion. Unfortunately, if this space is not
545 result of a transaction commit inserting a new memory buffer into the CIL, then
546 the difference in space required is removed from the transaction that causes
552 Hence we can grow the checkpoint transaction reservation dynamically as items
559 of the reservation against the maximum allowed transaction size. If we reach
564 transaction commit code.
566 If the transaction subsystem goes idle while we still have items in the CIL,
568 force will push the CIL to disk, and if the transaction subsystem stays idle,
578 Currently log items are pinned during transaction commit while the items are
581 that items get pinned once for every transaction that is committed to the log
583 for every outstanding transaction they were dirtied in. When each of these
587 as there is a 1:1 relationship with transaction commit and log item completion.
589 For delayed logging, however, we have an asymmetric transaction commit to
592 That is, we now have a many-to-one relationship between transaction commit and
594 log items becomes unbalanced if we retain the "pin on transaction commit, unpin
595 on transaction completion" model.
601 the CIL during a transaction commit, then we do not pin it again. Because there
619 A fundamental requirement for the CIL is that accesses through transaction
620 commits must scale to many concurrent commits. The current transaction commit
622 processors at once. The current transaction code does not go any faster than if
625 As a result, the delayed logging transaction commit code needs to be designed
629 	1. Locking out new transaction commits while flushing the CIL
633 Looking at the transaction commit and CIL flushing interactions, it is clear
640 The amount of time a transaction commit needs to hold out a flush is a
646 the transaction commit side.
648 Because of the number of potential transaction commit side holders, the lock
655 transaction commit or CIL flush side sleeps with the lock held.
658 compared to transaction commit for asynchronous transaction workloads - only
660 transaction commit concurrency due to cache line bouncing of the lock on the
663 The second serialisation point is on the transaction commit side where items
669 hold time once per transaction I think that contention is unlikely.
703 	4. Join item to transaction
707 		Attach log item to transaction
713 		Write commit LSN into transaction
715 		Attach transaction to log buffer
748 	4. Join item to transaction
752 		Attach log item to transaction
760 		Write CIL context sequence into transaction