Holes can lose birth time info if a block has a mix of birth times
The problem here is that when you truncate and write a file in the same
transaction group, the dbuf for the indirect block will be zeroed out to
deal with the truncation, and then written for the write.
During this process, we will lose hole birth time information for any
holes in the range. This is partly fixed by:
6513 partially filled holes lose birth time
which introduced dbuf_write_children_ready and would be the correct
time to do this processing; however, in the case where a dnode is being
freed, the old code includes necessary space accounting logic. We need a
hybrid approach between determining whether the block should be
converted to a higher-level hole in the zio pipeline, and doing it when
the dnode is being synced out.
No data to display