Lines Matching full:changes
26 XFS uses Write Ahead Logging for ensuring changes to the filesystem metadata
33 details logged are made up of the changes to in-core structures rather than
35 changes logged. Long running atomic modifications have individual changes
108 this provides a mechanism for complex changes to appear atomic from an external
167 take into account all the hidden changes that might occur.
311 existing changes in the new transaction that is written to the log.
313 That is, if we have a sequence of changes A through to F, and the object was
328 the aggregation of all the previous changes currently held only in the log.
347 the log - repeated operations to the same objects write the same changes to
365 Effectively, this gives us the maximum bound of outstanding metadata changes
384 contains all the changes from the previous changes. In other words, we have one
395 infrastructure to keep track of logical changes in memory prior to physically
396 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
400 changes to objects in memory outside the log buffer infrastructure. Because of
402 actually relatively easy to do - all the changes to logged items are already
408 One of the key changes that delayed logging makes to the operation of the
410 metadata changes from the size and number of log buffers available. In other
411 words, instead of there only being a maximum of 2MB of transaction changes not
425 of accumulating changes in memory for some period before writing them to the
445 Storing Changes
448 The problem with accumulating changes at a logical level (i.e. just using the
450 changes to the log buffers, we need to ensure that the object we are formatting
452 concurrent modification. Hence flushing the logical changes to the log would
464 Put simply, the current logging code formats the changes to each item into an
473 the changes in a format that is compatible with the log buffer writing code.
512 contains the latest changes.
531 Tracking Changes
534 Now that we can record transactional changes in memory in a form that allows
576 log replay - all the changes in all the objects in a given transaction must
600 Because the checkpoint is just another transaction and all the changes to log
602 code to write the changes into the log. To do this efficiently, we need to
614 those changes into the current checkpoint context. We then initialise a new
784 An example of the differences would be logging directory changes versus logging
785 inode changes. If you modify lots of inode cores (e.g. ``chmod -R g+w *``), then
827 space required by the log metadata. If this log metadata space changes as a
978 Lifecycle Changes
1082 and the design of the internal structures to avoid on disk format changes, we