Date: Thu, 10 Jan 2019 12:07:58 +0100 From: Borja Marcos <borjam@sarenet.es> To: Borja Marcos <borjam@sarenet.es> Cc: freebsd-fs@freebsd.org Subject: MY FAULT. Re: Interesting: ZFS scrub prefetch hurting sequential scrub performance? Message-ID: <77A3F53B-1574-474B-8CDB-ED6A6FECC1C1@sarenet.es> In-Reply-To: <C324E072-44FD-49D3-8B32-91E392833CFB@sarenet.es> References: <8ECF7513-9DFB-46EF-86BA-DB717D713792@sarenet.es> <C324E072-44FD-49D3-8B32-91E392833CFB@sarenet.es>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 4 Jan 2019, at 11:52, Borja Marcos <borjam@sarenet.es> wrote: >=20 > 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. >=20 > Once more, disabling prefetch for the scrub = (vfs.zfs.no_scrub_prefetch=3D1) solves the issue. >=20 > I suffered this problem on 11 at some point but I attributed it = (wrongly!) to hardware problems at the time. >=20 > 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 My apologies for the false alarm! My fault was to use a l2arc in the first place.=20 It seems that the latest updates have made l2arc more detrimental in = relatively low RAM situations. And yes, in those cases in which l2arc is = not recommended in the first place, scrub prefetch can make the = situation worse. But the blame should go to the improper usage of a l2arc, not to the = scrub prefetch instead.=20 Sorry for the confusion and false alarm, although I still think that = this lesson can be included in the guidelines for NOT using a l2arc for = she sake of it. Borja (jumping into a barrel full of tarr and feathers)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?77A3F53B-1574-474B-8CDB-ED6A6FECC1C1>