3 ms·

See Checking ZFS File System Integrity[1] in the ZFS administration guide. [1] http://docs.oracle.com/cd/E19082-01/817-2271/gbbwa/ http://docs.oracle.com/cd/E1

by wcoenen 14y ago

See Checking ZFS File System Integrity[1] in the ZFS administration guide. [1] http://docs.oracle.com/cd/E19082-01/817-2271/gbbwa/ http://docs.oracle.com/cd/E19082-01/817-2271/gbbwa/

joosters 14y ago
A useful link. But it is unclear just how much a 'zpool scrub' checks. Sure, it is double checking the block checksums to ensure that your file contents haven't become corrupted. But how much checking does it do to the ZFS structures themselves? At first glance, it certainly seems to depend upon some high-level ZFS data in order to start. A command like 'zpool scrub pool-name' still needs to navigate the ZFS pool data on disk in order to locate the named pool.
- dmpk2k 14y ago
  But how much checking does it do to the ZFS structures themselves? They're validated as well. Everything has a cryptographic checksum that's stored in the parent block, starting at the data and working all the way up to the top of the tree. Furthermore, the higher up the tree you go, the more redundant copies there are. The top of the tree has four copies, if I recall. This ignores support for mirroring and striping, which further improves data redundancy. But wait, there's more! Those four blocks aren't overwritten. ZFS is a copy-on-write filesystem (data and metadata) which behaves a lot like the persistent data structures that Clojure hackers are so fond of, so if the newest writes do not validate, it'll roll back to the newest valid commit of the tree. That's a nice way of saying that you're guessing given your experience with other filesystems. ZFS was a genuinely revolutionary filesystem, and doesn't behave like other filesystems, the sole OSS exception being BTRFS. Read up on it a bit, you'll find something interesting. :)
- X-Istence 14y ago
  The pool data is stored on disk, but when a pool is already available on the system that information is cached in memory and on disk in a zpool.cache file. That data may be stale or wrong, you can in that case export the zpool and re-import it (or if it is missing, re-import with -f to force it). It then reads the data about what zpool a disk belongs to from disk. That data is itself stored in multiple locations so that it is unlikely that all of those are corrupted, after importing the disks you can run scrub. If the pool metadata itself is corrupted, generally you can roll-back to a previous time when the data is not corrupted. This document: http://docs.oracle.com/cd/E19082-01/817-2271/6mhupg6qg/index.html http://docs.oracle.com/cd/E19082-01/817-2271/6mhupg6qg/index... describes fairly well what all the options along the way are. None of the failure modes described would be any better if there was a fsck tool available... in all file systems it is going to cause dataloss.

by wcoenen 14y ago

See Checking ZFS File System Integrity[1] in the ZFS administration guide. [1] http://docs.oracle.com/cd/E19082-01/817-2271/gbbwa/ http://docs.oracle.com/cd/E19082-01/817-2271/gbbwa/

joosters 14y ago

A useful link. But it is unclear just how much a 'zpool scrub' checks. Sure, it is double checking the block checksums to ensure that your file contents haven't become corrupted. But how much checking does it do to the ZFS structures themselves? At first glance, it certainly seems to depend upon some high-level ZFS data in order to start. A command like 'zpool scrub pool-name' still needs to navigate the ZFS pool data on disk in order to locate the named pool.

dmpk2k 14y ago
But how much checking does it do to the ZFS structures themselves? They're validated as well. Everything has a cryptographic checksum that's stored in the parent block, starting at the data and working all the way up to the top of the tree. Furthermore, the higher up the tree you go, the more redundant copies there are. The top of the tree has four copies, if I recall. This ignores support for mirroring and striping, which further improves data redundancy. But wait, there's more! Those four blocks aren't overwritten. ZFS is a copy-on-write filesystem (data and metadata) which behaves a lot like the persistent data structures that Clojure hackers are so fond of, so if the newest writes do not validate, it'll roll back to the newest valid commit of the tree. That's a nice way of saying that you're guessing given your experience with other filesystems. ZFS was a genuinely revolutionary filesystem, and doesn't behave like other filesystems, the sole OSS exception being BTRFS. Read up on it a bit, you'll find something interesting. :)
X-Istence 14y ago
The pool data is stored on disk, but when a pool is already available on the system that information is cached in memory and on disk in a zpool.cache file. That data may be stale or wrong, you can in that case export the zpool and re-import it (or if it is missing, re-import with -f to force it). It then reads the data about what zpool a disk belongs to from disk. That data is itself stored in multiple locations so that it is unlikely that all of those are corrupted, after importing the disks you can run scrub. If the pool metadata itself is corrupted, generally you can roll-back to a previous time when the data is not corrupted. This document: http://docs.oracle.com/cd/E19082-01/817-2271/6mhupg6qg/index.html http://docs.oracle.com/cd/E19082-01/817-2271/6mhupg6qg/index... describes fairly well what all the options along the way are. None of the failure modes described would be any better if there was a fsck tool available... in all file systems it is going to cause dataloss.