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

Dimitry Andric dim at FreeBSD.org
Thu Dec 14 14:46:58 UTC 2017

On 14 Dec 2017, at 14:43, O. Hartmann <ohartmann at walstatt.org> wrote:
> Am Thu, 14 Dec 2017 14:09:39 +0100
> Daniel Nebdal <dnebdal at gmail.com> schrieb:
>> On Thu, Dec 14, 2017 at 12:48 PM, O. Hartmann <ohartmann at walstatt.org> wrote:
>>> 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.
>> This is kind of to be expected - for whatever reason, resilvers seem
>> to go super slow at first and then speed up significantly. Just don't
>> ask me how long "at first" is - I'd give it several (more) hours.

Hopefully this will get better in the future, please read:



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 223 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20171214/47b2fe33/attachment.sig>

More information about the freebsd-current mailing list