ZFS RAIDZ1: resilvering at <17.3M/s => abyssal slow ...

O. Hartmann ohartmann at walstatt.org
Thu Dec 14 11:49:15 UTC 2017

Hello out there,

I had to replace a HDD on a RAIDZ1 pool comprised from 4 HDDs, each 3 TB (netto size of
the pool is about 8-9 TB, the used amount is reported to be ~ 6TB).

I just started the rebuild/resilvering process and watch the pool crwaling at ~ 18 MB/s.
At the moment, there is no load on the array, the host is a IvyBridge XEON with 4 core/8
threads and 3,4 GHz and 16 GB of RAM. The HDDs are attached to a on-board SATA II (300
MB/s max) Intel chip - this just for the record.

Recently, I switch on the "sync" attribute on most of the defined pools's zfs filesystems
- I also use a SSD for ZIL/L2ARC caching, but it seems to be unused recently in FreeBSD
CURRENT's ZFS - this from a observers perspective only.

When scrubbing, I see recently also reduced performance on the pool, so I'm wondering
about the low throughput at the very moment when resilvering is in progress.

If the "perspective" of "zpool status" is correct, then I have to wait after two hours
for another 100 hours - ~ 4 days? Ups ... I think there is something badly misconfigured
or missing.

The pool is not "tuned" in any very sophisticated way, since I trust the kernels ability
to scale automatically - if I'm not wrong for amd64 ...

Are there any aspects to look at?

Thanks in advance,


O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20171214/11c778b9/attachment.sig>

More information about the freebsd-current mailing list