Lines Matching refs:flush

19 This allows the log to avoid needing to flush each change to disk before
172 trying to get the lock on object A to flush it to the log buffer. This appears
192 Hence we avoid the need to lock items when we need to flush outstanding
344 the CIL would look like this before the flush:
364 And after the flush the CIL head is empty, and the checkpoint context log
390 start, while the checkpoint flush code works over the log vector chain to
446 that are currently committing to the log. When we flush a checkpoint, the
468 is, we need to flush the CIL and potentially wait for it to complete. This is a
470 and push if required. Indeed, placing the current sequence checkpoint flush in
547 checkpoint flush code.
553 a "background flush" and is done on demand. This is identical to
599 CIL commit/flush lock. If we pin the object outside this lock, we cannot
604 (or not pinning, as the case may be). Hence we must hold the CIL flush/commit
630 The amount of time a transaction commit needs to hold out a flush is a
632 while we are holding out a CIL flush, so at the moment that means it is held
639 really needs to be a sleeping lock - if the CIL flush takes the lock, we do not
645 transaction commit or CIL flush side sleeps with the lock held.
656 commit/flush exclusion. It also needs to be an exclusive lock but it is only
663 path that triggers a CIL flush (i.e. whatever triggers the log force) will enter
755 		lock CIL flush
758 		unlock CIL flush