Jeremy Archer wrote: > Thanks for the explanation. > >> .... a dirty >> buffer goes onto the >> list corresponding to the txg it belongs to. > > Ok. I see that all dirty buffers are put on a per txg list. > This is for easy synchronization, makes sense. > > The per dmu_buf_impl_t details are a bit fuzzy. > > I see there can be more than one dirty buffers per dmu_buf_impl_t. > Are these multiple "edited versions" of the same buffer that occurred in the > same txg? > If a dbuf is "dirtied" in more than one txg, then it will have multiple dirty records. So these are the "edited versions" separated by transaction group boundaries.
> Looks like the dirty buffer (leaf) records point to an arc_buf_t, which is > presumably yet un-cached (until it is synched out). > Correct. It becomes "cached" when it obtains an "identity", which does not happen until we write it out. > db_data_pending points to the most current of these. Seems that > db_data_pending > always points to the last (newest) dirty buffer for the dmu buffer. > No, db_data_pending points to the record that is currently being written. > A the moment, the purpose of maintaining the per-dbuf dirty list eludes me. > (Maybe to dispose of these except for the latest one, which will be written > out to disk) See my comment above. We must maintain separate versions or else get "future leaks" (record data written in txg n+1 in txg n) and possibly trash our checksum (we must not change the data once the checksum is calculated). > > Also: what is BP_IS_HOLE? I see it has no birth_txg.
