I accidentally dd'ed the wrong disc /dev/sdb when it should be /dev/sdc but i stopped in something like 2 sec. and a small part of my 2tb disc was overwritten with openSUSE milestone 3 the ruby baked yast flavor :).
I was able to see, access and use my data in the /dev/sdb disc, but not after the reboot, so at the moment unsuccessfully am trying to mount with different options like: mount -t btrfs -o compress=lzo /dev/sdb /mnt/Kyrios mount: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Or mount /dev/sdb /mnt/Kyrios mount: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so Or mount -t /dev/sdb /mnt/Kyrios mount: can't find /mnt/Kyrios in /etc/fstab Or mount -t btrfs -o compress=lzo /dev/sdb /mnt/Kyrios mount: wrong fs type, bad option, bad superblock on /dev/sdb, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so LABEL=btrfs /mnt/Kyrios btrfs noatime, compress=lzo 0 0 bash: /mnt/Kyrios: Is a directory btrfs subvolume list /mnt/Kyrios/Media ERROR: error accessing '/mnt/Kyrios/Media' My btrfs fi show output: failed to read /dev/sr0 Label: 'Kyrios' uuid: b5d84724-f93a-4478-a3eb-3c45c7e5ac72 Total devices 1 FS bytes used 1.57TB devid 1 size 1.82TB used 1.58TB path /dev/sdb My btrfs fi df output: btrfs fi df /dev/sdb ERROR: couldn't get space info on '/dev/sdb' - Inappropriate ioctl for device My btrfsck output: btrfsck /dev/sdb Check tree block failed, want=20971520, have=14982790533290893935 Check tree block failed, want=20971520, have=14982790533290893935 Check tree block failed, want=20971520, have=15644090216945910062 Check tree block failed, want=20971520, have=14982790533290893935 Check tree block failed, want=20971520, have=14982790533290893935 read block failed check_tree_block Couldn't read chunk root Segmentation fault (core dumped) My blkid output: /dev/sdb: LABEL="Kyrios" UUID="b5d84724-f93a-4478-a3eb-3c45c7e5ac72" UUID_SUB="22a11e2f-7347-4aee-b490-9d9a8f3b9425" TYPE="btrfs" /dev/sda1: UUID="A270FB3270FB0C33" TYPE="ntfs" /dev/sda2: LABEL="Swap" UUID="517fc7b8-3b92-4f21-8761-4ffb8af74e0d" TYPE="swap" /dev/sda3: UUID="e3be6b5b-0d8c-4731-bfe1-10510fd50b79" TYPE="ext4" dmesg output: btrfs loaded device label Kyrios devid 1 transid 38257 /dev/sdb btrfs: use lzo compression btrfs: disk space caching is enabled btrfs bad tree block start 14982790533290893935 20971520 btrfs bad tree block start 15644090216945910062 20971520 btrfs: failed to read chunk root on sdb mnt-Kyrios.mount mount process exited status=32 failed to mount /mnt/Kyrios defined by systemd dependency failed for local file systems unit local-fs.target has failed unit mnt-Kyrios.mount entered failed state. Useful info: I am using btrfs-progs 0.20 rc1 and kernel 3.9.2 The whole (1.8TB) disc is pure btrfs with no gpt or other formats like ext4 is just created by mkfs.btrfs /dev/sdb and all my files are in subvolumes Root, Media, Home, Opt, etc. What i did till now was to use wipefs and delete the opensuse and the dos filesystems that were created by the dd command on top of the pure btrfs disc. Before i use the wipefs i wasnt able to see sdb btrfs info at all with blkid command but now i can as can confirm the blkid output above. At the moment i play with etc/fstab but adding the line: UUID=b5d84724-f93a-4478-a3eb-3c45c7e5ac72 /mnt/Kyrios btrfs defaults,compress=lzo 0 1 Or /dev/sdb /mnt btrfs defaults,compress=lzo 0 1 leaves my system unbootable and asks me to see the journalctl Not sure what i do next. Can anyone spot the error? How can i fix it? Big headache with lots of valuable data (no i did not use snapper for backup as was a new disc migration and left it for a month in the back of my mind:() Any help will be appreciated. -- 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