On Wed, 7 Jun 2017 15:09:02 +0200 Adam Borowski <[email protected]> wrote:
> On Wed, Jun 07, 2017 at 01:10:26PM +0300, Timofey Titovets wrote: > > 2017-06-07 13:05 GMT+03:00 Stefan G. Weichinger <[email protected]>: > > > Am 2017-06-07 um 11:37 schrieb Timofey Titovets: > > > > > >> btrfs scrub start /mnt_path do this trick > > >> > > >> After, you can find info with paths in dmesg > > > > > > thank you, I think I have the file, it's a qemu-img-file. > > > I try cp-ing it to another fs first, but assume this will fail, right? > > > > 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. https://superuser.com/questions/622541/what-does-dd-conv-sync-noerror-do http://www.debianadmin.com/recover-data-from-a-dead-hard-drive-using-dd.html https://wiki.archlinux.org/index.php/disk_cloning Or just stick with dd_rescue and not try to correct people's perfectly good suggestions with completely wrong and harmful ones. -- With respect, Roman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
