Lines Matching full:changes

12 logged are made up of the changes to in-core structures rather than on-disk
13 structures. Other objects - typically buffers - have their physical changes
26 changes in the new transaction that is written to the log.
28 That is, if we have a sequence of changes A through to F, and the object was
43 the aggregation of all the previous changes currently held only in the log.
65 the log - repeated operations to the same objects write the same changes to
82 Effectively, this gives us the maximum bound of outstanding metadata changes
101 contains all the changes from the previous changes. In other words, we have one
112 infrastructure to keep track of logical changes in memory prior to physically
113 formatting the changes in a transaction to the log buffer. Hence we cannot avoid
117 changes to objects in memory outside the log buffer infrastructure. Because of
119 actually relatively easy to do - all the changes to logged items are already
125 One of the key changes that delayed logging makes to the operation of the
127 metadata changes from the size and number of log buffers available. In other
128 words, instead of there only being a maximum of 2MB of transaction changes not
142 of accumulating changes in memory for some period before writing them to the
162 Storing Changes
165 The problem with accumulating changes at a logical level (i.e. just using the
167 changes to the log buffers, we need to ensure that the object we are formatting
169 concurrent modification. Hence flushing the logical changes to the log would
181 Put simply, the current logging code formats the changes to each item into an
190 the changes in a format that is compatible with the log buffer writing code.
229 contains the latest changes.
248 Tracking Changes
251 Now that we can record transactional changes in memory in a form that allows
293 log replay - all the changes in all the objects in a given transaction must
317 Because the checkpoint is just another transaction and all the changes to log
319 code to write the changes into the log. To do this efficiently, we need to
331 those changes into the current checkpoint context. We then initialise a new
501 An example of the differences would be logging directory changes versus logging
502 inode changes. If you modify lots of inode cores (e.g. ``chmod -R g+w *``), then
544 space required by the log metadata. If this log metadata space changes as a
695 Lifecycle Changes
799 and the design of the internal structures to avoid on disk format changes, we