zfs scrub enable by default

[Karl Denninger]

On 8/5/2020 09:15, Bob Friesenhahn wrote:
> On Tue, 4 Aug 2020, Karl Denninger wrote:
>
>> 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.
>
> Did you remember to set copies=2 or copies=3 for zfs filesystems where 
> you hope not to experience data loss?  It needs to be set as soon as 
> possible since it only applies to new files.  This is a way to get 
> more media redundancy, although the whole drive may fail.
>
> Zfs scrub is not going to protect your precious data from loss given 
> just one drive unless you increase the copies setting.  Zfs itself 
> already uses redundant copies for its own data structures.
>
copies=2 does nothing if the drive itself fails (as opposed to a handful 
of sectors failing on said drive.)

SSDs rarely lose a block undetected by their own controller. 
More-commonly when they fail they fail HARD and the entire volume 
becomes inaccessible immediately.  The same is frequently (but less 
frequently than with an SSD) true for spinning rust.  In my experience 
with various "non-removable" spinning rust going back to the original 
5Mb winchester devices in a decent percentage of the instances the 
device becomes either completely inaccessible all at once or it may as 
well be since the unreadable sectors are numerous enough and the 
timeouts on attempted reads long enough that recovery of the 
non-impacted data will frequently take days (or worse.)

Don't even get me started on controller/adapter failures.  I've had two 
in my career that scribbled on everything connected to them at once.  
Even ZFS in a RaidZx or mirrored configuration won't protect you from 
that.  You either have backups or you have nothing.

As I said, a workstation or laptop is, in such a configuration, backed 
up to some other storage (external, either plugged in or on a network) 
and if the drive fails it is replaced and restored. ZFS makes this easy 
to do and also quite economical in terms of time and either storage or 
network bandwidth with its snapshot capability.

The latter is also a reason to use ZFS standing alone, irrespective of 
redundancy of data storage.

I've had scrub catch incipient errors (but you have to look at the stats 
to know it found and fixed the blocks) before the volume failed and was 
able to replace the bad volume before it puked entirely.  I appreciate 
that when it happens but the point here is that turning on automated 
scrubs is like automated patrol reads on an old-style RAID adapter; it 
sounds great right up until it can cause trouble without benefit.  To 
have it as an option in the installer is a good thing, but to silently 
turn it on, especially if it's done during an upgrade where it wasn't on 
before, is IMHO a bad thing as it has at least a decent probability of 
producing unpleasant surprises.

-- 
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/20200805/4ad92ac9/attachment.bin>