Date: Wed, 5 Aug 2020 10:18:14 +1000 (AEST) From: Grant Gray <grant@gray.id.au> To: Ryan Moeller <ryan@ixsystems.com> Cc: Warner Losh <imp@bsdimp.com>, freebsd-fs <freebsd-fs@freebsd.org>, George Wilson <george.wilson@delphix.com> Subject: Re: zfs scrub enable by default Message-ID: <105090343.294898.1596586694925.JavaMail.zimbra@gray.id.au> In-Reply-To: <CAGuotKD0mCS3KmMA-EGL1uH_fByYOhMKbPVDoTdB8dg5kC-u9g@mail.gmail.com> References: <cca34d1a-1892-41ec-ce45-84865100c6e1@FreeBSD.org> <CAJjvXiEXEdAFXpXkGvt4fymA17kNdp6XkZV5taGKLoP2GvMHbw@mail.gmail.com> <d1b580da-1539-5fc9-f7a3-3f013bba4ef3@FreeBSD.org> <CANCZdfq2PneFvB4rnz2iGu5srFFFjs8N=7FwRO3DYjosESWXtQ@mail.gmail.com> <CAGuotKD0mCS3KmMA-EGL1uH_fByYOhMKbPVDoTdB8dg5kC-u9g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > It's easy to recover from lost performance by stopping the scrub and > reconfiguring the periodic script. It's harder to recover from data > loss by changing your configuration after the fact. > You are making a great example of the two core issue with this proposition. 1. That the side-effect of performance loss due to scrubbing is benign. I have a customer using hardware iSCSI HBA's attached to ZFS zvols. This is a notoriously bad case wrt to sync performance (yes this will get better 'soon' with pending patches). A scrub results in most/all of the attached systems BSOD'ing. This is just a personal example; others will suffer reduced transaction rates, poor customer experience, lost revenue etc. 2. That scrubbing PREVENTS data loss. Scrubbing can only tell you about data loss AFTER it happens. Yes, it could alert you to a problem that prevents further data loss, but it's already too late. Scrubbing is not a substitute for RAID, backups and proactive SMART testing.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?105090343.294898.1596586694925.JavaMail.zimbra>