Lines Matching refs:transactions
30 of transactions, their contents and the log sequence number (LSN) of the
52 transactions. These transaction are known as rolling transactions, and require
70 Another feature of the XFS transaction subsystem is that most transactions are
72 filled (a log buffer can hold multiple transactions) or a synchronous operation
73 forces the log buffers holding the transactions to disk. This means that XFS is
74 doing aggregation of transactions in memory - batching them, if you like - to
84 buffers are full and under IO, then no more transactions can be committed until
86 be to able to issue enough transactions to keep the log buffers full and under
97 transactions A through D are committed to disk in the same log buffer.
135 recovered filesystem is concerned, there may be many thousands of transactions
172 This introduces lots of scope for deadlocks with transactions that are already
197 asynchronous transactions to the log. The differences between the existing
296 no later transactions should be replayed, either.
332 context and attach that to the CIL for aggregation of new transactions.
335 committed items and effectively allow new transactions to be issued while we
395 Once this transfer is done, the CIL can be unlocked and new transactions can
423 committed transactions with the log sequence number of the transaction commit.
424 This allows transactions to be issued asynchronously even though there may be
430 To do this, transactions need to record the LSN of the commit record of the
433 mechanism, it does not work for delayed logging because transactions are not
435 transactions is required.
447 operations that track transactions that have not yet completed know what
462 aggregation of multiple synchronous transactions if there are already
463 synchronous transactions being flushed. Investigation of the performance of the
479 transactions to remain untouched (i.e. commit an asynchronous transaction, then
503 there are lots of transactions that only contain an inode core and an inode log
524 large enough to handle arbitrary sized checkpoint transactions. This
537 rolling transactions for an example of this). Hence we *must* always have
557 As mentioned early, transactions can't grow to more than half the size of the
584 transactions is completed, they will unpin the item once. As a result, the item
585 only becomes unpinned when all the transactions complete and there are no
586 pending transactions. Thus the pinning and unpinning of a log item is symmetric
621 code does not break down even when there are transactions coming from 2048
635 the number of concurrent transactions that can be trying to commit at once is
637 limit here is in the order of several hundred concurrent transactions for a
664 are inserted into the CIL. Because transactions can enter this code