From owner-freebsd-fs@freebsd.org Wed Aug 5 04:36:29 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9C0AD3AA078 for ; Wed, 5 Aug 2020 04:36:29 +0000 (UTC) (envelope-from grant@gray.id.au) Received: from mail.agc.net.au (mail.agc.net.au [167.86.119.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4BLzNC0HTdz4Hrm for ; Wed, 5 Aug 2020 04:36:25 +0000 (UTC) (envelope-from grant@gray.id.au) Received: from localhost (localhost [127.0.0.1]) by mail.agc.net.au (Postfix) with ESMTP id 2F01118A5BC for ; Wed, 5 Aug 2020 14:35:49 +1000 (AEST) Received: from mail.agc.net.au ([127.0.0.1]) by localhost (mail.agc.net.au [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id D5fwG32m18sC for ; Wed, 5 Aug 2020 14:35:30 +1000 (AEST) Received: from localhost (localhost [127.0.0.1]) by mail.agc.net.au (Postfix) with ESMTP id BF38318A4DD for ; Wed, 5 Aug 2020 14:35:29 +1000 (AEST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.agc.net.au BF38318A4DD X-Virus-Scanned: amavisd-new at mail.agc.net.au Received: from mail.agc.net.au ([127.0.0.1]) by localhost (mail.agc.net.au [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Tb7rvuHfROVk for ; Wed, 5 Aug 2020 14:35:28 +1000 (AEST) Received: from mail.agc.net.au (mail.agc.net.au [167.86.119.123]) by mail.agc.net.au (Postfix) with ESMTP id D05AE18A4D3 for ; Wed, 5 Aug 2020 14:35:25 +1000 (AEST) Date: Wed, 5 Aug 2020 14:35:20 +1000 (AEST) From: Grant Gray To: freebsd-fs Message-ID: <1647249742.296540.1596602120083.JavaMail.zimbra@gray.id.au> Subject: Re: zfs scrub enable by default MIME-Version: 1.0 X-Originating-IP: [167.86.119.123] X-Mailer: Zimbra 8.8.15_GA_3945 (ZimbraWebClient - FF80 (Linux)/8.8.15_GA_3953) Thread-Index: 9N3dwL/pDlx/Oe/PmMJI7K8/UIgGHw== Thread-Topic: zfs scrub enable by default X-Rspamd-Queue-Id: 4BLzNC0HTdz4Hrm X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.15 / 15.00]; FAKE_REPLY(1.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_FIVE(0.00)[6]; HAS_XOIP(0.00)[]; FROM_HAS_DN(0.00)[]; R_DKIM_ALLOW(-0.20)[gray.id.au:s=30D3F2DC-EB1E-11E9-943D-4BC9C5489560]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; NEURAL_HAM_LONG(-1.01)[-1.014]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gray.id.au:+]; DMARC_POLICY_ALLOW(-0.50)[gray.id.au,quarantine]; NEURAL_HAM_SHORT(-0.15)[-0.153]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:51167, ipnet:167.86.118.0/23, country:DE]; MID_RHS_MATCH_FROM(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 04:36:29 -0000 On 5/8/20 1:36 pm, PK1048.COM wrote: > On Aug 4, 2020, at 8:18 PM, Grant Gray via freebsd-fs wrote: > >> 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. > Scrubbing does not directly prevent data loss. Scrubbing identifies data returned from the underlying device as corrupt or incorrect. If the zpool has sufficient redundancy, then no data is lost. > > But, normal ZFS operation also identifies incorrect date returned from the underlying device(s). You've taken me out of context; I was replying to an implication that scrubbing helps prevent data loss. It obviously doesn't because disks don't care about your arbitrary scrub interval and will fail as they see fit. Your tolerance to their bit destroying whims is determined, as you rightly point out, by the level of redundancy at play. If you have no redundancy, scrubbing only tells you that you are already screwed. If you do have redundancy, scrubbing tells you how many N's you have left. If you are out of N's, see above. But this isn't a discussion about the value of scrubbing (my apologies to all for indulging in the digression). That was never in question. Regardless of if/how much redundancy we have, we should scrub within an interval that makes sense in the context of our backup strategy to ensure there is always one known-good copy of the data. > While I have only managed a few hundred drives under ZFS, I cannot recall one case where a proactive scrub found bad data _before_ normal operations. Once a checksum error is reported via `zpool status` then I have found a scrub useful to determine the extent of the drive failure. > > I know there are others with thousands of drives managed under ZFS and their experience may differ. > > In terms of whether the periodic scrub should be enabled by default, I am undecided, as I can see both sides of the argument. I would prefer to make it a user choice during installation as one of the ZFS options (such as native 4K drives, ashift=12 or mirrored swap). Make the default enabled, but by putting it in the installation options, those who know they need it disabled can make sure it is off from day one and not have a rude surprise the first time it runs (35 days after installation). > The suggestion of making periodic scrub an install-time option came up earlier in the thread and seems like a good compromise, though I'm not convinced it should be enabled by default because, as I started previously, not scrubbing does not produce unexpected behaviour, whereas scrubbing can.