Lines Matching refs:transactions

27 of transactions, their contents and the log sequence number (LSN) of the
49 transactions.  These transaction are known as rolling transactions, and require
67 Another feature of the XFS transaction subsystem is that most transactions are
69 filled (a log buffer can hold multiple transactions) or a synchronous operation
70 forces the log buffers holding the transactions to disk. This means that XFS is
71 doing aggregation of transactions in memory - batching them, if you like - to
81 buffers are full and under IO, then no more transactions can be committed until
83 be to able to issue enough transactions to keep the log buffers full and under
94 transactions A through D are committed to disk in the same log buffer.
132 recovered filesystem is concerned, there may be many thousands of transactions
168 This introduces lots of scope for deadlocks with transactions that are already
193 asynchronous transactions to the log. The differences between the existing
290 no later transactions should be replayed, either.
326 context and attach that to the CIL for aggregation of new transactions.
329 committed items and effectively allow new transactions to be issued while we
389 Once this transfer is done, the CIL can be unlocked and new transactions can
416 committed transactions with the log sequence number of the transaction commit.
417 This allows transactions to be issued asynchronously even though there may be
423 To do this, transactions need to record the LSN of the commit record of the
426 mechanism, it does not work for delayed logging because transactions are not
428 transactions is required.
440 operations that track transactions that have not yet completed know what
455 aggregation of multiple synchronous transactions if there are already
456 synchronous transactions being flushed. Investigation of the performance of the
472 transactions to remain untouched (i.e. commit an asynchronous transaction, then
495 there are lots of transactions that only contain an inode core and an inode log
516 large enough to handle arbitrary sized checkpoint transactions. This
529 rolling transactions for an example of this).  Hence we *must* always have
549 As mentioned early, transactions can't grow to more than half the size of the
575 transactions is completed, they will unpin the item once. As a result, the item
576 only becomes unpinned when all the transactions complete and there are no
577 pending transactions. Thus the pinning and unpinning of a log item is symmetric
611 code does not break down even when there are transactions coming from 2048
625 the number of concurrent transactions that can be trying to commit at once is
627 limit here is in the order of several hundred concurrent transactions for a
654 are inserted into the CIL. Because transactions can enter this code