> How would you describe the difference between the file system > checking utility and zpool scrub? Is zpool scrub lacking in its > verification of the data?
To answer the second question first, yes, zpool scrub is lacking, at least to the best of my knowledge (I haven't looked at the ZFS source in a few months). It does not verify that any internal data structures are correct; rather, it simply verifies that data and metadata blocks match their checksums. This makes it useless in situations such as those described in bugs 6458218/6634517, where a pool cannot be imported because its metadata is inconsistent. It also would not repair a damaged directory, for instance. If a directory in ZFS is damaged, its files become permanently inaccessible; if the same happens in UFS, fsck will create new links to the files in the lost+found directory. It's as if the UFS fsck could only work on mounted file systems, and could tell you that there was a problem, but not fix it. > How would you describe the difference between the > data recovery utility and ZFS's normal data recovery process? What do you consider the “normal data recovery process” ? Take, for instance, the pool which Borys just mentioned on this list, which causes a kernel panic at import. I'm not sure how ZFS can recover from that. A data recovery utility would (for instance) scan the pool, locate a healthy-looking uberblock (or, failing that, look for one or more top-level file system blocks), and traverse the tree down from that point, pulling files from the disk as it goes. When a damaged metadata block is found, a scan can be performed for blocks which are candidate blocks that belong under it; or potential block numbers can be extracted from the damaged block itself. This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
