What does zfs scrub do

This scenario results in downtime that is proportional to the size of the file system being checked. Instead of requiring an explicit utility to perform the necessary checking, ZFS provides a mechanism to perform routine checking of all inconsistencies.

This feature, known as scrubbing , is commonly used in memory and other systems as a method of detecting and preventing errors before they result in a hardware or software failure. Whenever ZFS encounters an error, either through scrubbing or when accessing a file on demand, the error is logged internally so that you can obtain quick overview of all known errors within the pool.

The simplest way to check data integrity is to initiate an explicit scrubbing of all data within the pool. This operation traverses all the data in the pool once and verifies that all blocks can be read. This operation might negatively impact performance, though the pool's data should remain usable and nearly as responsive while the scrubbing occurs.

To initiate an explicit scrub, use the zpool scrub command. For example:. The status of the current scrubbing operation can be displayed by using the zpool status command. You can stop a scrubbing operation that is in progress by using the -s option. In most cases, a scrubing operation to ensure data integrity should continue to completion. Stop a scrubbing operation at your own discretion if system performance is impacted by the operation. Routine scrubbing has the side effect of preventing power management from placing idle disks in low-power mode.

If it is, the reported scrub rate will be the sum of the reported rates that the scrub can achieve on each vdev. I'm not going to try to hold forth on the conditions when this is likely, because it depends on a lot of things as far as I can tell from the kernel code. I think it's more likely when you have single objects files, directories, etc whose blocks are spread across multiple vdevs.

If your IO system has total bandwidth limits across all disks, this will clamp your maximum scrub speed. For raidz vdevs, the visible scrub rate will be this total bandwidth limit; for mirror vdevs, it will be the limit divided by how many mirrors you have. This finally gives us an answer to how you know if your scrub is fast or slow. The fastest rate a raidz scrub can report is your total disk bandwidth across all disks and the fastest rate a mirror scrub can report is your single disk bandwidth times the number of vdevs.

If you're reasonably close to this or if you've hit what you know is your system's overall disk bandwidth limit , the better. The further away from this the worse off you are, either because your scrub has descended into random IO or because you're hitting tunable limits or both at once for extra fun.

Much of this also applies to resilvers because scrubs and resilvers share most of the same code, but it gets kind of complicated and I haven't attempted to decode the resilver specific part of the kernel ZFS code.

Scrubs have two sorts of IO they do. For ZFS objects like directories and dnodes, the scrub actually needs to inspect the contents of the disk blocks so it tries to prefetch them and then synchronously reads the data through the regular ARC read paths. This IO is normal IO, does not get counted in the scrub progress report, and does not do things like check parity blocks or all mirrored copies.

Then for all objects including directories, dnodes, etc the scrub issues a special scrub 'read everything asynchronously' read that does check parity, read all mirrors, and so on.

The above lines will schedule a zpool scrub to take place at 2 am on the first of every month. At 1 pm , it will check the pool status to make sure the scrub went well and has completed.

Congratulations, you now have the peace of mind that can only come from monthly emails letting you know that your files are safe! Sign in. About Me Stack Overflow. Scheduling automated ZFS scrubs. Brian Smith Follow. Some things I love: my family, building things, helping people, tinkering. I like tinkering and sometimes I write about it. Written by Brian Smith Follow.