Lines Matching refs:changes

9 logged are made up of the changes to in-core structures rather than on-disk
10 structures. Other objects - typically buffers - have their physical changes
23 changes in the new transaction that is written to the log.
25 That is, if we have a sequence of changes A through to F, and the object was
40 the aggregation of all the previous changes currently held only in the log.
62 the log - repeated operations to the same objects write the same changes to
79 Effectively, this gives us the maximum bound of outstanding metadata changes
98 contains all the changes from the previous changes. In other words, we have one
109 infrastructure to keep track of logical changes in memory prior to physically
110 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
114 changes to objects in memory outside the log buffer infrastructure. Because of
116 actually relatively easy to do - all the changes to logged items are already
122 One of the key changes that delayed logging makes to the operation of the
124 metadata changes from the size and number of log buffers available. In other
125 words, instead of there only being a maximum of 2MB of transaction changes not
139 of accumulating changes in memory for some period before writing them to the
161 The problem with accumulating changes at a logical level (i.e. just using the
163 changes to the log buffers, we need to ensure that the object we are formatting
165 concurrent modification. Hence flushing the logical changes to the log would
177 Put simply, the current logging code formats the changes to each item into an
186 the changes in a format that is compatible with the log buffer writing code.
225 contains the latest changes.
246 Now that we can record transactional changes in memory in a form that allows
287 log replay - all the changes in all the objects in a given transaction must
311 Because the checkpoint is just another transaction and all the changes to log
313 code to write the changes into the log. To do this efficiently, we need to
325 those changes into the current checkpoint context. We then initialise a new
493 An example of the differences would be logging directory changes versus logging
494 inode changes. If you modify lots of inode cores (e.g. chmod -R g+w *), then
536 space required by the log metadata. If this log metadata space changes as a
788 and the design of the internal structures to avoid on disk format changes, we