#OPENZFS SCRUB ALL POOLS SOFTWARE#
#OPENZFS SCRUB ALL POOLS PASSWORD#
#OPENZFS SCRUB ALL POOLS OFFLINE#

The recommended frequency at which you should scrub the data depends on the quality of the underlying disks. You need to do it manually, and it's highly recommended that you do it on a regularly scheduled interval. Scrubbing ZFS storage pools is not something that happens automatically. So, when scrubbing your data, the probability is that either the checksum will match, and you have a good data block, or it won't match, and you have a corrupted data block. For reference, uncorrected ECC memory errors will happen on about 50 orders of magnitude more frequently, with the most reliable hardware on the market. However, because of SHA-256, you have a 1 in 2^256 or 1 in 10^77 chance that a corrupted block hashes to the same SHA-256 checksum. This can be changed to using the SHA-256 algorithm, although it may not recommended, as calculating the SHA-256 checksum is more costly than fletcher4. Currently, this is the 'fletcher4' algorithm, which is a 256-bit algorithm, and it's fast. Every block from top-to-bottom is checksummed using an appropriate algorithm by default. While ZFS is performing a scrub on your pool, it is checking every block in the storage pool against its known checksum. Further, just like you can scrub ECC RAM on a live running system, without downtime, you should be able to scrub your disks without downtime as well. This is an old technique that has been around for a while, so it's surprising that it's not available in the standard suite of journaled filesystems. This is similar in technique to ECC RAM, where if an error resides in the ECC DIMM, you can find another register that contains the good data, and use it to fix the bad register. With ZFS on Linux, detecting and correcting silent data errors is done through scrubbing the disks. These errors are known as 'silent data errors', and there is really nothing you can do about it with the standard GNU/Linux filesystem stack.

#OPENZFS SCRUB ALL POOLS SOFTWARE#

Unfortunately, Linux software RAID has no idea which is good or bad, and from the perspective of ext3 or ext4, it will get good data if read from the disk containing the good block, and corrupted data from the disk containing the bad block, without any control over which disk to pull the data from, and fixing the corruption. You may only have a bad block on one disk, but a good block on another disk. Second, the filesystem, such as ext3 or ext4, knows nothing of the underlying data structures, such as LVM or RAID. Depending on the size of the disks, this downtime could take hours. For root partitions, this further means booting from another medium, like a CDROM or USB stick. So, you must use the 'umount' command to unmount your disks, before the fsck.

#OPENZFS SCRUB ALL POOLS OFFLINE#

First, you must fsck the disk offline if you are intending on fixing data errors. However, it has a couple major drawbacks. In GNU/Linux, we have a number of filesystem checking utilities for verifying data integrity on the disk.

Only one scrub session is permitted at a time.4. The command creates lots of IO, so use it judiciously.

To scrub the pool techrx, use the following: On redundant systems (raidz or mirror), inconsistencies will be repaired.

When run, the command checks all data in the pool for checksum consistency. Unlike of the fsck command which had to be run on an unmounted filesystem (read: downtime), the zpool command has a scrub option which works on a mounted, living filesystem. For you worriers, there is a command you can use to make sure everything is okay with your filesystems. With ZFS, data are always consistent on disk.

#OPENZFS SCRUB ALL POOLS PASSWORD#

ZFS filesystems are always clean, so even in the worst case of a power outage bringing a system down, you will never be asked to give the root password for system maintenance again. How do you use fsck with a ZFS filesystem? The answer is that you do not. ZFS will change the way UNIX people think about filesystems.

Openzfs scrub all pools