Lines Matching refs:vectors

179 simply copies the memory these vectors point to into the log buffer during
228 buffer is to support splitting vectors across log buffer boundaries correctly.
239 handled in exactly the same manner as the existing log vectors are handled.
312 items are stored as log vectors, we can use the existing log buffer writing
316 way it separates the writing of the transaction contents (the log vectors) from
339 to store the list of log vectors that need to be written into the transaction.
340 Hence log vectors need to be able to be chained together to allow them to be
401 efficient way to track vectors, even though it seems like the natural way to do
403 vectors and break the link between the log item and the log vector means that
405 the log vector chaining. If we track by the log vectors, then we only need to
409 vectors in one checkpoint transaction. I'd guess this is a "measure and
491 of log vectors in the transaction).
496 format structure. That is, two vectors totaling roughly 150 bytes. If we modify
497 10,000 inodes, we have about 1.5MB of metadata to write in 20,000 vectors. Each
501 buffer format structure for each buffer - roughly 800 vectors or 1.51MB total
664 an ordering loop after writing all the log vectors into the log buffers but
756 		Chain log vectors and buffers together
759 		write log vectors into log