On Mon, Sep 28, 2009 at 10:16:20AM -0700, Richard Elling wrote: > On Sep 28, 2009, at 3:42 PM, Albert Chin wrote: > >> On Mon, Sep 28, 2009 at 12:09:03PM -0500, Bob Friesenhahn wrote: >>> On Mon, 28 Sep 2009, Richard Elling wrote: >>>> >>>> Scrub could be faster, but you can try >>>> tar cf - . > /dev/null >>>> >>>> If you think about it, validating checksums requires reading the >>>> data. >>>> So you simply need to read the data. >>> >>> This should work but it does not verify the redundant metadata. For >>> example, the duplicate metadata copy might be corrupt but the problem >>> is not detected since it did not happen to be used. >> >> Too bad we cannot scrub a dataset/object. > > Can you provide a use case? I don't see why scrub couldn't start and > stop at specific txgs for instance. That won't necessarily get you to a > specific file, though.
If your pool is borked but mostly readable, yet some file systems have cksum errors, you cannot "zfs send" that file system (err, snapshot of filesystem). So, you need to manually fix the file system by traversing it to read all files to determine which must be fixed. Once this is done, you can snapshot and "zfs send". If you have many file systems, this is time consuming. Of course, you could just rsync and be happy with what you were able to recover, but if you have clones branched from the same parent, which a few differences inbetween shapshots, having to rsync *everything* rather than just the differences is painful. Hence the reason to try to get "zfs send" to work. But, this is an extreme example and I doubt pools are often in this state so the engineering time isn't worth it. In such cases though, a "zfs scrub" would be useful. -- albert chin (ch...@thewrittenword.com) _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
