zfs receive is still slow when processing FREE records
Dan McDonald of OmniTI reported that one of their customers was seeing poor
performance of "zfs receive" of a sparse zvol, despite having applied the fix
for 24744 and 24530 (illumos bug 3834).
Investigation revealed that dbuf_free_range() was taking the slow path, causing
zfs_free_range_recv_miss to be incremented, and each call took more than 500ms.
The problem is that the previous fixes have incorrect logic for determining
when we can take the fast path:
if (start >= dn->dn_unlisted_l0_blkid * dn->dn_datablksz)
// take the fast path
The problem is that "start" is a block ID, which we are comparing to an offset.
Therefore the "* blksz" is unnecessary, and causes us to essentially never
take the fast path.
No data to display