I believe it was physical corruption of the media. Strange thing is last time it happened to me it also managed to replicate the bad blocks over to my backup server replicated with SNDR...
And yes, it IS read only, and a scrub will NOT actively clean up corruption in snapshots. It will DETECT corruption, but if it's unrecoverable, that's that. It's unrecoverable. If there's not enough redundancy in the pool, I'm ok with the data not being recoverable. But wouldn't there be a way to purge out the bad blocks if for example it was only in a single bad file out of millions of files, and I didn't care about the file in question? I don't want to recover the file, I want to have a working version of my pool+snapshots minus the tiny bit that was obviously corrupt. Barring another solution, I'd have to take the pool in question, delete the bad file, and delete ALL the snapshots. Then restore the old snapshots from backup to another pool, and copy over the current data from the pool that had a problem over to the new pool. I can get most of my snapshots back that way, with the best known current data sitting on top as the active data set. Problem is with hundreds of snapshots plus compression, zfs send/recv takes over 24 hours to restore a full backup like that to a new storage device. Last time this happened to me, I just had to say goodbye to all my snapshots and deal with it, all over a couple of kilobytes of temp files. -- This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
