Scrubbing without redundancy

[djdwosk97]

Is there any point in running weekly scrubs if there's no redundancy?

 

[jde]

It will at least tell you if any files have corruption. It will not fix them. Assuming you have a good backup that's not also been corrupted, you could delete the corrupted file that's been identified by the scrub and restore from backup.

 

[DrKK]

Another option when you have no redundancy is to set "copies = 2" in the ZFS dataset properties. To my knowledge the scrub *will* be able to utilize the second copy on the single device to make repairs during a scrub.

Of course, this means that file blocks are written twice, so you get half the capacity.

 

[djdwosk97]

Another option when you have no redundancy is to set "copies = 2" in the ZFS dataset properties. To my knowledge the scrub *will* be able to utilize the second copy on the single device to make repairs during a scrub.

Of course, this means that file blocks are written twice, so you get half the capacity.

Well I need the total space, so at that point I may as well just buy more drives.

 

[jgreco]

Another option when you have no redundancy is to set "copies = 2" in the ZFS dataset properties. To my knowledge the scrub *will* be able to utilize the second copy on the single device to make repairs during a scrub.

This is correct; ZFS will use any available redundancy.

 

[Mlovelace]

If you're running a stripe array then the data must be ephemeral in nature, so why bother trying to scrub.

 

[jgreco]

Because it's nice to detect the fact that there's a problem, of course.

 

[Joshua Parker Ruehlig]

ZFS stores redundant copies of metadata so ZFS can find and repair that.

 

[djdwosk97]

ZFS stores redundant copies of metadata so ZFS can find and repair that.

So then it would be worthwhile to scrub even without redundancy.

Are there any downsides to scrubbing (other than it being another load on the cpu)?

 

[jgreco]

Load on the CPU. IO capacity reduction on the disks. Busywork. Nothing that bad.

 

[Arwen]

One advantage of using a striped array, is using "copies=2" on CERTAIN datasets.
Meaning if you have 95% of the pool allocated to media that can be replaced, (perhaps
not easily, but replacable), and using a separate dataset for backups of important
data with "copies=2".

Note that with "copies=1", metadata is already duplicated. With "copies=2", the
number of metadata is triplicated.

All that said, if you suffer a total disk loss, the pool is likely gone. So "copies=2"
is not as good as RAID-Z1 or Mirroring.

I wish there were more options. Ideally I would want my media, (which is 90% of
used data in my pool), stored with RAID-Z1. And everything else with RAID-Z2. So
my ideal type of storage system would have the redundancy at the dataset / file
system level, not the pool level. But neither ZFS or BTRFS support this hybrid.

 

[diehard]

There's a chance the load on a drive could make the pool fail faster.

Of course if it does it was going to fail at some time anyway...

 

[Arwen]

There's a chance the load on a drive could make the pool fail faster.

Of course if it does it was going to fail at some time anyway...

Yes. But, one advantage to scrubing is that hopefully you loose some blocks FIRST.
Thus, giving you warning, (and if not metadata, loss of only 1 or a few files).