Date: Tue, 04 Aug 2020 02:08:43 +0200 From: "Ronald Klop" <ronald-lists@klop.ws> To: "Paul Pathiakis via freebsd-fs" <freebsd-fs@freebsd.org>, "Josh Paetzel" <josh@tcbug.org> Subject: Re: zfs scrub enable by default Message-ID: <op.0ostctlvkndu52@sjakie> In-Reply-To: <e2979bd2-6dad-4c28-b76b-9e29fcf7e5ab@www.fastmail.com> References: <cca34d1a-1892-41ec-ce45-84865100c6e1@FreeBSD.org> <24edb075-155c-439d-1ef5-541893036429@freebsd.org> <0d1d14c9-64ba-368c-b2f4-56efa741cc5e@inbox.lv> <e2979bd2-6dad-4c28-b76b-9e29fcf7e5ab@www.fastmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 04 Aug 2020 01:33:49 +0200, Josh Paetzel <josh@tcbug.org> wrote: > > > On Mon, Aug 3, 2020, at 4:41 PM, John Long via freebsd-fs wrote: >> On 03/08/2020 20:25, Allan Jude wrote: >> > On 2020-08-03 12:10, Steve Wills wrote: >> >> Hi, >> >> >> >> I wonder why we don't enable zfs periodic scrub by default? >> >> >> >> >> https://svnweb.freebsd.org/base/head/usr.sbin/periodic/periodic.conf?view=markup#l162 >> >> >> >> >> >> Anyone happen to know? >> >> >> >> Thanks, >> >> Steve >> >> >> >> _______________________________________________ >> >> freebsd-fs@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > >> > I think switching this to on-by-default is a good thing. >> > >> > To be clear, which the check is part of 'periodic daily', it only >> > triggers a scrub if it has been more than 35 days since the last >> scrub. >> > >> > FreeNAS already has does this, and that accounts for a large number of >> > FreeBSD ZFS deployments. >> >> There is a difference. FreeNAS is an appliance. It should minimize the >> need for management. >> >> FreeBSD is the base OS. It should do as little as possible so people can >> set it up the way we want rather than spend days or weeks unbreaking >> surprising, non-standard behavior and hundreds of tweaks for everybody >> who requested them. >> >> > There is tuning you can do in ZFS to try to lessen the impact of a >> scrub >> > on your production workloads. >> >> That's up to the guy running the box to do or not to do. >> >> > The periodic script lets you select which pools to include (defaults >> to >> > all), so you can tune it to only scrub your root pool every 35 days, >> and >> > not the large pool that might take too long to scrub or whatever. It >> > also lets you set a different threshold for each pool. >> >> A NAS appliance could benefit from something like this. A generic OS >> cannot. >> >> > So I don't see any reason not to enable it by default, and just >> document >> > how to adjust it if people really need to disable it. Honestly, I >> think >> > those who are disabling it are doing themselves a disservice. >> >> It's offensive for you to presume to think you know better what the >> other guy needs than he does himself. Thank you for clarifying it >> though, I think it's valuable to understand the thinking of people who >> want to coopt the OS into their personal playground. >> >> /jl >> _______________________________________________ >> freebsd-fs@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >> > > ZFS needs scrub in the same way that UFS needs fsck. (in that i you > don't scrub a ZFS volume for long enough and you don't fsck a UFS volume > for long enough they will stop being useful filesystems) If you've ever > had the joy of running UFS on a volume so large you couldn't fsck it or > run say XFS on a volume so large you couldn't run xfs_repair you'll know > that you can get away with that for a while, but eventually the chickens > come home to roost and you'll be restoring from tape or failing over to > your DR site, or complaining about lost data. (Note that XFS is > journaled and is far more resilient than UFS to this sort of thing but > it's still an issue) > > (Thankfully UFS added background fsck years ago but there was a time > when a FreeBSD system wouldn't go multiuser until fsck had completed and > really large volumes (say greater than 2TB, (and remember this was 15+ > years ago before you start talking about your laptop has a 2TB SSD) > weren't feasible unless you disabled fsck or had 9+ hours to spare every > time you rebooted. > > When FreeBSD grew ZFS support the periodic scrub script didn't exist. > Thankfully we don't have a "Allow perfect to be the enemy of the good" > stance and in spite of that shortcoming (and many others) ZFS went in. > > Over time the FreeBSD ZFS support was iterated on, a scrub periodic > script was added...but it was left disabled by default: POLA violation > and all that. > > The reality is having scrub off is (in the vast majority of cases) the > wrong thing to do. I say that as someone who has nearly an exabyte in > ZFS right now, and lead the team that brought ZFS based FreeNAS to the > world. So the suggestion to "fix the glitch" and enable periodic scrubs > makes perfect sense to me. Those who don't know any better will just > magically receive the benefit of something they should've been doing all > along. Those who do know better have a lot of time on their hands (at > least judging by this thread!) and with way less typing than the length > of these emails can disable the periodic script. Sounds win-win to me. > > As far as the personal playground comment....we're all just trying to do > the right thing for the biggest group of people while knowing all along > that perfection for everyone is an unachievable goal (however it is > possible that while chasing perfection we may achieve greatness). As an > interesting data point, no version of FreeBSD ever shipped with fsck > disabled even if it was an unusable feature for some of the users.... > > (Just my ten cents, my two cents is free) > +1 to enable by default (All my ZFS systems scrub, except my FreeBSD I found out in this mailinglist today.)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.0ostctlvkndu52>