On Sun, Jun 12, 2016 at 3:22 PM, Maximilian Böhm <win...@gmail.com> wrote: > Hi there, I did something terribly wrong, all blame on me. I wanted to > write to an USB stick but /dev/sdc wasn't the stick in this case but > an attached HDD with GPT and an 8 TB btrfs partition… > > $ sudo dd bs=4M if=manjaro-kde-16.06.1-x86_64.iso of=/dev/sdc > 483+1 Datensätze ein > 483+1 Datensätze aus > 2028060672 bytes (2,0 GB, 1,9 GiB) copied, 16,89 s, 120 MB/s > > So, shit. > > $ sudo btrfs check --repair /dev/sdc > enabling repair mode > No valid Btrfs found on /dev/sdc > Couldn't open file system > > $ sudo btrfs-find-root /dev/sdc > No valid Btrfs found on /dev/sdc > ERROR: open ctree failed > > $ sudo btrfs-show-super /dev/sdc --all > superblock: bytenr=65536, device=/dev/sdc > --------------------------------------------------------- > ERROR: bad magic on superblock on /dev/sdc at 65536 > > superblock: bytenr=67108864, device=/dev/sdc > --------------------------------------------------------- > ERROR: bad magic on superblock on /dev/sdc at 67108864 > > superblock: bytenr=274877906944, device=/dev/sdc > --------------------------------------------------------- > ERROR: bad magic on superblock on /dev/sdc at 274877906944 > >
OK but none of these can work anyway because the tools work based on fixed offsets. By pointing the tool to /dev/sdc the wrong offset is always being used, because originally the drive had a partition. By default GPT disks offset the 1st partition 1MiB, or 2048 using 512 byte sectors assuming the drive uses 512 byte logical sectors (and most still do). What you should do is run gdisk /dev/sdc and it'll find the backup GPT at the end of the drive, and offer to fix up the primary one. And now you can point the tools to /dev/sdc1 (or whatever partition is for Btrfs). 2GIB of Btrfs metadata is a lot of missing metadata though. So even though btrfs-show-super will find the 3rd superblock, chances are it's going to point to metadata somewhere in those first 2GiB that were overwritten, but maybe not. It might be possible to get a -o ro mount at least and start copying off some data. If it's ro mountable, it might be possible to put /dev/sdc1 on an overlay, and then fix the overlay rather than the original with btrfsck - maybe it can fix up enough such that you'll just get piles of read errors for the data that's missing rather than hitting some brick wall and stopping. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
