Lines Matching refs:transaction

23 changes in the new transaction that is written to the log.
28 transaction:
39 In other words, each time an object is relogged, the new transaction contains
45 (increasing) LSN of each subsequent transaction - the LSN is effectively a
46 direct encoding of the location in the log of the transaction.
49 transactions.  These transaction are known as rolling transactions, and require
50 a special log reservation known as a permanent transaction reservation. A
51 typical example of a rolling transaction is the removal of extents from an
52 inode which can only be done at a rate of two extents per transaction because
53 of reservation size limitations. Hence a rolling extent removal transaction
64 dirtier as they get relogged, so each subsequent transaction is writing more
67 Another feature of the XFS transaction subsystem is that most transactions are
72 minimise the impact of the log IO on transaction throughput.
74 The limitation on asynchronous transaction throughput is the number and size of
110 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
125 words, instead of there only being a maximum of 2MB of transaction changes not
154 	6. No performance regressions for synchronous transaction workloads.
169 running. For example, a transaction has object A locked and modified, but needs
170 the delayed logging tracking lock to commit the transaction. However, the
180 transaction commit while the item is locked in the transaction. Instead of
188 rewriting can all be done while the object is locked during transaction commit,
251 exist once the object has been included in a transaction.
260 transaction.
272 in transaction commit order, so when an object is relogged it is removed from
285 need to be written as an atomic transaction. The need for all the objects to be
286 written as an atomic transaction comes from the requirements of relogging and
287 log replay - all the changes in all the objects in a given transaction must
289 a transaction is not replayed because it is not complete in the log, then
293 transaction. Fortunately, the XFS log code has no fixed limit on the size of a
294 transaction, nor does the log replay code. The only fundamental limit is that
295 the transaction cannot be larger than just under half the size of the log.  The
297 be at least one complete transaction in the log at any given time. If a
298 transaction is larger than half the log, then there is the possibility that a
299 crash during the write of a such a transaction could partially overwrite the
300 only complete previous transaction in the log. This will result in a recovery
304 Apart from this size requirement, a checkpoint transaction looks no different
305 to any other transaction - it contains a transaction header, a series of
307 perspective, the checkpoint transaction is also no different - just a lot
309 might need to tune the recovery transaction object hash size.
311 Because the checkpoint is just another transaction and all the changes to log
315 transaction. The current log write code enables us to do this easily with the
316 way it separates the writing of the transaction contents (the log vectors) from
317 the transaction commit record, but tracking this requires us to have a
323 at the same time a checkpoint transaction is started. That is, when we remove
332 workloads, just like the existing transaction commit code does. This, however,
336 To ensure that we can be writing an item into a checkpoint transaction at
337 the same time another transaction modifies the item and inserts the log item
338 into the new CIL, then checkpoint transaction commit code cannot use log items
339 to store the list of log vectors that need to be written into the transaction.
396 run transaction committed processing for the log items (i.e. insert into AIL
409 vectors in one checkpoint transaction. I'd guess this is a "measure and
415 One of the key aspects of the XFS transaction subsystem is that it tags
416 committed transactions with the log sequence number of the transaction commit.
418 future operations that cannot be completed until that transaction is fully
421 force can be issued to force the dependent transaction to disk immediately.
424 transaction. This LSN comes directly from the log buffer the transaction is
425 written into. While this works just fine for the existing transaction
438 Then, instead of assigning a log buffer LSN to the transaction commit LSN
472 transactions to remain untouched (i.e. commit an asynchronous transaction, then
473 force the log at the LSN of that transaction) and so the higher level code
478 The big issue for a checkpoint transaction is the log space reservation for the
479 transaction. We don't know how big a checkpoint transaction is going to be
485 A typical transaction reserves enough space in the log for the worst case space
486 usage of the transaction. The reservation accounts for log record headers,
487 transaction and region headers, headers for split regions, buffer tail padding,
489 transaction. While some of this is fixed overhead, much of it is dependent on
490 the size of the transaction and the number of regions being logged (the number
491 of log vectors in the transaction).
507 reservation does it cover? We account for space used by the transaction
523 the write reservation (the actual space available to the transaction) after
524 every checkpoint transaction completion. Unfortunately, if this space is not
537 result of a transaction commit inserting a new memory buffer into the CIL, then
538 the difference in space required is removed from the transaction that causes
544 Hence we can grow the checkpoint transaction reservation dynamically as items
551 of the reservation against the maximum allowed transaction size. If we reach
556 transaction commit code.
558 If the transaction subsystem goes idle while we still have items in the CIL,
560 force will push the CIL to disk, and if the transaction subsystem stays idle,
569 Currently log items are pinned during transaction commit while the items are
572 that items get pinned once for every transaction that is committed to the log
574 for every outstanding transaction they were dirtied in. When each of these
578 as there is a 1:1 relationship with transaction commit and log item completion.
580 For delayed logging, however, we have an asymmetric transaction commit to
583 That is, we now have a many-to-one relationship between transaction commit and
585 log items becomes unbalanced if we retain the "pin on transaction commit, unpin
586 on transaction completion" model.
592 the CIL during a transaction commit, then we do not pin it again. Because there
609 A fundamental requirement for the CIL is that accesses through transaction
610 commits must scale to many concurrent commits. The current transaction commit
612 processors at once. The current transaction code does not go any faster than if
615 As a result, the delayed logging transaction commit code needs to be designed
619 	1. Locking out new transaction commits while flushing the CIL
623 Looking at the transaction commit and CIL flushing interactions, it is clear
630 The amount of time a transaction commit needs to hold out a flush is a
636 the transaction commit side.
638 Because of the number of potential transaction commit side holders, the lock
645 transaction commit or CIL flush side sleeps with the lock held.
648 compared to transaction commit for asynchronous transaction workloads - only
650 transaction commit concurrency due to cache line bouncing of the lock on the
653 The second serialisation point is on the transaction commit side where items
659 hold time once per transaction I think that contention is unlikely.
692 	4. Join item to transaction
696 		Attach log item to transaction
702 		Write commit LSN into transaction
704 		Attach transaction to log buffer
737 	4. Join item to transaction
741 		Attach log item to transaction
749 		Write CIL context sequence into transaction