Project

General

Profile

Bug #4915

zfs receive is still slow when processing FREE records

Added by Alex Reece over 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
zfs - Zettabyte File System
Start date:
2014-06-06
Due date:
% Done:

0%

Estimated time:
Difficulty:
Bite-size
Tags:
needs-triage

Description

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.

Also available in: Atom PDF