Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 4 Jan 2019 11:52:37 +0100
From:      Borja Marcos <borjam@sarenet.es>
To:        Borja Marcos <borjam@sarenet.es>
Cc:        freebsd-fs@freebsd.org
Subject:   Re: Interesting: ZFS scrub prefetch hurting sequential scrub performance?
Message-ID:  <C324E072-44FD-49D3-8B32-91E392833CFB@sarenet.es>
In-Reply-To: <8ECF7513-9DFB-46EF-86BA-DB717D713792@sarenet.es>
References:  <8ECF7513-9DFB-46EF-86BA-DB717D713792@sarenet.es>

next in thread | previous in thread | raw e-mail | index | archive | help


> On 3 Jan 2019, at 11:34, Borja Marcos <borjam@sarenet.es> wrote:
>=20
>=20
> Hi,
>=20
> I have noticed that my scrubs have become painfully slow. I am =
wondering wether I=E2=80=99ve just hit some worst case or maybe
> there is some interaction between the ZFS sequential scrub and scrub =
prefetch. I don=E2=80=99t recall seeing this behavior
> before the sequential scrub code was committed.=20
>=20
> Did I hit some worst case or should scrub prefetch be disabled with =
the new sequential scrub code?

I have done a test with the old scrub code (vfs.zfs.zfs_scan_legacy=3D1) =
and I see a very similar behavior, with the=20
scrub stalling again.

Once more, disabling prefetch for the scrub =
(vfs.zfs.no_scrub_prefetch=3D1) solves the issue.

I suffered this problem on 11 at some point but I attributed it =
(wrongly!) to hardware problems at the time.

Not I=E2=80=99ve just found a talk about a new prefetch mechanism for =
the scrub by Tom Caputi. Could it be the problem?
https://www.youtube.com/watch?v=3Dupn9tYh917s





Borja.






Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C324E072-44FD-49D3-8B32-91E392833CFB>