Am 2017-06-07 um 15:52 schrieb Adam Borowski: > On Wed, Jun 07, 2017 at 06:48:48PM +0500, Roman Mamedov wrote: >> On Wed, 7 Jun 2017 15:09:02 +0200 >> Adam Borowski <kilobyte@xxxxxxxxxx> wrote: >>>> Yes, because btrfs will return -EIO >>>> So try dd_rescue >>> >>> Or even plain dd conv=noerror. Both will do a faithful analogue of a >>> physical disk with a silent data corruption on the affected sectors. >> >> Yeah, except "plain dd conv=noerror" will produce a useless corrupted image, >> because it will be shifted forward by the number of unreadable bytes after the >> first error. >> >> You also need the "sync" flag in there. > > Doh, yeah. > >> Or just stick with dd_rescue and not try to correct people's perfectly good >> suggestions with completely wrong and harmful ones. > > On the other hand, you have dd everywhere, while dd_rescue is not available > on most bootable media not specifically made for rescue purposes. And > installing extra software when your disk is already unsound but mostly > working might be risky. I had ddrescue (without "_") on the given server (gentoo linux) and was able to copy the 2 files via ddrescue -n -e1 $filename /other_fs/$filename I then cp-ied the file back via plain "cp" and the VM started again. Looks good, now also btrfs scr is happy! Now it's interesting if there is an underlying corruption happening in the hardware (on disks). thanks so far, Stefan -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
