Date: Wed, 5 Aug 2020 14:35:20 +1000 (AEST) From: Grant Gray <grant@gray.id.au> To: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: zfs scrub enable by default Message-ID: <1647249742.296540.1596602120083.JavaMail.zimbra@gray.id.au>
next in thread | raw e-mail | index | archive | help
On 5/8/20 1:36 pm, PK1048.COM wrote: > On Aug 4, 2020, at 8:18 PM, Grant Gray via freebsd-fs <freebsd-fs@freebsd.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1647249742.296540.1596602120083.JavaMail.zimbra>