Date: Tue, 4 Aug 2020 10:47:50 +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: <2038290194.249397.1596502070473.JavaMail.zimbra@gray.id.au> 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 4 Aug, 2020, at 9:33 AM, 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) > These are some fun (and real) historical anecdotes but, other than bit-rot, they do not represent current reality as these problems have been largely solved or the momentum has shifted to better filesystems (such as ZFS and XFS). > 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. > > -- > > Thanks, > > Josh Paetzel I think you are projecting a false characterisation of the average FreeBSD user and workload. FreeBSD is not an appliance and is not, in my experience, deployed or used by inexperienced users for any serious use-case. Who exactly is the user/use-case you are advocating for? There seems to be a conflation of purpose of scrubbing and general disk health; the point of a scrub is to catch bit errors in files that are infrequently accessed, that would otherwise not be detected in real-time. The value of that is largely dictated by whether you have RAID, and your backup strategy. A scrub does not tell you anything about the state of blocks that are not in use (or the overall health of a disk; ref smartd). Other people in this thread have already alluded to the fact that scrubbing can be detrimental, or even disastrous, for many of the workloads FreeBSD is used for. Excess scrubbing is a waste of energy and potentially reduces the working life of the disks. What I (and others in this thread) are getting at is setting a scrub schedule is so context specific that getting it right for the general case is near impossible, because there is no general case. Not scrubbing by default does not lead to unexpected behaviour. Scrubbing by default can and does lead to unexpected behaviour. People who care about their data use RAID and will determine a scrub schedule that suits their context. I take your point that, for a specific type of user, scrubbing by default makes sense. I'm just not sure that type of user is the benchmark for deciding FreeBSD system policies. If a user won't bear the cognitive load of understanding how to protect their own data, I would suggest FreeBSD is not for them and there are better options that will protect them better, by default (such as Ubuntu).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2038290194.249397.1596502070473.JavaMail.zimbra>