Anton B. Rang wrote:
This might be impractical for a large file system, of course. It might be easier to have a 'zscavenge' that would recover data, where possible, from a corrupted file system. But there should be at least one of these. Losing a whole pool due to the corruption of a couple of blocks of metadata is a Bad Thing.
That could be handy for any number of data-transport, borked-system-recovery and even some forensic-like tasks:
zscavenge badpool | zfs recvSo, suppose a user has a few hundred gb of data that they'd like copied directly onto our fileserver. They bring me a ZFS-formatted external USB drive. Instead of mounting it and messing with their data, I zscavange /dev/usbdevice, and then write that into a pool that I'm comfortable messing with.
It works just as well for someone trying to recover a truly borked system. One could recover the data without making any changes whatsoever to the drive, so that I can put everything back the way I found it -- in case I can't fix it, the next person who tries to fix it has a clean slate.
-Luke
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
