Lines Matching refs:object

14 than any other object (except maybe the superblock buffer) so keeping the
18 modifications to a single object to be carried in the log at any given time.
20 recording a new change to the object. XFS does this via a method called
22 new change to the object is recorded with a *new copy* of all the existing
25 That is, if we have a sequence of changes A through to F, and the object was
35 	    <object written to disk>
39 In other words, each time an object is relogged, the new transaction contains
43 that an object being relogged does not prevent the tail of the log from ever
96 That is, a single log buffer may contain multiple copies of the same object,
163 changes to the log buffers, we need to ensure that the object we are formatting
164 is not changing while we do this. This requires locking the object to prevent
166 require us to lock every object, format them, and then unlock them again.
169 running. For example, a transaction has object A locked and modified, but needs
172 trying to get the lock on object A to flush it to the log buffer. This appears
185 point to the memory buffer rather than the object itself, we now have a copy of
188 rewriting can all be done while the object is locked during transaction commit,
222 The memory buffer and associated vector need to be passed as a single object,
223 but still need to be associated with the parent object so if the object is
238 self-describing object that can be passed to the log buffer write code to be
250 to be the object that is used to track committed objects as it will always
251 exist once the object has been included in a transaction.
257 completion, after which they are unpinned and can be written to disk. An object
258 that is in the AIL can be relogged, which causes the object to be pinned again
272 in transaction commit order, so when an object is relogged it is removed from
309 might need to tune the recovery transaction object hash size.
508 reservation by tracking the space currently used by the object in the CIL and
509 then calculating the increase or decrease in space used as the object is
581 completion relationship. Every time an object is relogged in the CIL it goes
591 pin the object the first time it is inserted into the CIL - if it is already in
599 CIL commit/flush lock. If we pin the object outside this lock, we cannot
603 object, we have a race with CIL being flushed between the check and the pin
730 are entered and completed is the object considered clean.