zfs scrub enable by default
Charles Sprickman
spork at bway.net
Mon Aug 3 21:12:11 UTC 2020
> On Aug 3, 2020, at 4:25 PM, Allan Jude <allanjude at freebsd.org> 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 tuning you can do in ZFS to try to lessen the impact of a scrub
> on your production workloads.
>
>
> 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.
>
> 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.
I 100% agree. I think often FreeBSD defaults tend to favor the experienced user and throw the newbies under the bus. In this case there were arguments against that amounted to “What about people running large production systems”, to which my answer would be, “What about them? They are experienced, read all the mailing lists, would know right away what was happening when they saw a scrub running, and already know how to disable it and could make the case for disabling or swapping in their own solution”.
Contrast with the random home user, noob, casual user who would likely benefit from whatever data protection, pre-emptive failure notification, etc. this would provide (for example I’ve had a scrub show me a failing drive before SMART did).
Charles
>
> --
> Allan Jude
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20200803/d65ac47e/attachment.sig>
More information about the freebsd-fs
mailing list