From owner-freebsd-fs@freebsd.org Wed Aug 5 01:21:35 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 57C293A579A for ; Wed, 5 Aug 2020 01:21:35 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from smtp.simplesystems.org (smtp.simplesystems.org [65.66.246.90]) (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 4BLv3L2mrHz46wk for ; Wed, 5 Aug 2020 01:21:34 +0000 (UTC) (envelope-from bfriesen@simple.dallas.tx.us) Received: from scrappy.simplesystems.org (scrappy.simplesystems.org [65.66.246.73]) by smtp.simplesystems.org (8.14.4+Sun/8.14.4) with ESMTP id 0751LPbI007218; Tue, 4 Aug 2020 20:21:26 -0500 (CDT) Date: Tue, 4 Aug 2020 20:21:25 -0500 (CDT) From: Bob Friesenhahn X-X-Sender: bfriesen@scrappy.simplesystems.org To: Grant Gray cc: freebsd-fs Subject: Re: zfs scrub enable by default In-Reply-To: <105090343.294898.1596586694925.JavaMail.zimbra@gray.id.au> Message-ID: References: <105090343.294898.1596586694925.JavaMail.zimbra@gray.id.au> User-Agent: Alpine 2.20 (GSO 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (smtp.simplesystems.org [65.66.246.90]); Tue, 04 Aug 2020 20:21:26 -0500 (CDT) X-Rspamd-Queue-Id: 4BLv3L2mrHz46wk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bfriesen@simple.dallas.tx.us designates 65.66.246.90 as permitted sender) smtp.mailfrom=bfriesen@simple.dallas.tx.us X-Spamd-Result: default: False [-2.97 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.009]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.04)[-1.039]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dallas.tx.us]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.62)[-0.620]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:7018, ipnet:65.64.0.0/13, country:US]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] 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 01:21:35 -0000 On Wed, 5 Aug 2020, 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. Any reasonable zfs pool should have sufficient hardware redundancy to allow it sufficient time to work without losing data before a human is able to notice and replace the failing hardware. You make a good point about scrubbing reporting data loss after it happens, but usually there will not be actual data loss if the pool is designed properly with sufficient redundancy. In this case, the scrub failure may be an indication of decreased redundancy and need for attention from an attendant human. In some cases there might just be a minor media failure and a resilver will put a redundant copy of the data elsewhere. If the pool has more redundancy, then there is less need to scrub it often. Scrub simple duplex mirrors more often than raidz3. There is an old saying "If a tree falls in the forest and no one is there to hear the noise, does it make a sound?". This is somewhat applicable to zfs since if the data is so derelict that no one accesses it at all so that it can be detected to be going 'bad', is it really that important to protect? Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt