zfs scrub enable by default

[Karl Denninger]

On 8/4/2020 21:21, Bob Friesenhahn wrote:
> On Wed, 5 Aug 2020, Grant Gray via freebsd-fs 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.
>
> Any reasonable zfs pool should have sufficient hardware redundancy to 
> allow it sufficient time to work without losing data before a human is 
> able to notice and replace the failing hardware.

You assume much.

Let me give you two allegedly "degenerate" cases that are actually not 
degenerate at all.

1. A laptop or workstation.  It is backed up.  It uses ZFS because it's 
faster, and I can establish a filesystem for some project very easily 
and quickly, it's segregated, I can work on it and destroy it trivially 
when done.  I can set quotas on that, etc.  If I want to move its 
mountpoint, I can trivially do so. And so on.  Note that here there is 
no redundancy at all; no raidZx, no mirroring, etc.  I'm merely using it 
for convenience.

2. The same, but with multiple BEs.  Same idea, but now I can have 
multiple OS versions and change between them for a given boot very 
quickly while leaving my user data (and application software) alone.  
VERY useful if I'm doing code development on the OS (and I do that once 
in a while) or application development and want to test against 
different FreeBSD revisions (which I do a LOT.) Again, I don't get a wet 
crap about redundancy, but I care very much about the convenience.

My laptop is set up with ZFS and has exactly one storage device in it.  
I don't consider that foolish at all for the above reasons (and it has 
kept me from hair-pulling exercises when drm-kmod problems bit people, 
including me), but a scrub on an automated "schedule" basis for that 
machine is IMHO cray-cray material.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20200804/fe14b36b/attachment.bin>