zfs scrub enable by default

Tue Aug 4 00:08:51 UTC 2020

On Tue, 04 Aug 2020 01:33:49 +0200, Josh Paetzel <josh at 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 at freebsd.org mailing list
>> >> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> >> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at 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 at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at 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.)