Re: Recovering from btrfs error Couldn't read chunk root.
Hello, Unrecoverable? I know i cant mount and have access but my data are still there intact ( as i was using them till the reboot) i shouldn't be able to extract/recover them to another disc? With any magic command without mounting? Any other solutions? As We Know chunk Tree really plays a vital role in btrfs filesystem, And it seems your chunk Tree is totally damaged, And it is ok to recover chunk tree if block groups are ok, Unfortunately, dd seems to destroy some of them. Maybe you can refers to commands btrfs-restore's help, i guess it doesn't work either. Thank, Wang http://bpaste.net/show/118112/ On 29 July 2013 15:06, Wang Shilong wangshilong1...@gmail.com wrote: 在 2013-7-29，上午2:12，Kyriakos kyriakosbrastia...@gmail.com 写道： Just tried it as you said with the -v option enabled This is my output: http://bpaste.net/show/118112/ This is a *long* email, and seems that btrfs list refuse it. Device extent: devid = 1, start = 1667558801408, len = 1073741824, chunk offset = 1663255445504 Couldn't map the block 626309926912 btrfs: volumes.c:1020: btrfs_num_copies: Assertion `!(ce-start logical || ce-start + ce-size logical)' failed. Aborted (core dumped) Strange enough, we don't find any chunks during scanning process. And seems this is unrecoverable ~_~ Wang, Any thoughts? On 28 July 2013 08:17, Wang Shilong wangshilong1...@gmail.com wrote: Hello, It seems Btrfs Chunk Tree is damaged, so you can not mount Btrfs filesystem any more. However, you can try the latest Btrfs-progs, Miao Xie implements chunk tree recover function. The url is: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git you can try it: btrfs chunk-recover -v dev This is Time-consuming, because it will scan the whole disk. And also, please catch output of processing(this is helpful to us if the recovery fails, -v option enable this). Thanks, Wang -- 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
Re: Recovering from btrfs error Couldn't read chunk root.
在 2013-7-29，上午2:12，Kyriakos kyriakosbrastia...@gmail.com 写道： Just tried it as you said with the -v option enabled This is my output: http://bpaste.net/show/118112/ This is a *long* email, and seems that btrfs list refuse it. Device extent: devid = 1, start = 1667558801408, len = 1073741824, chunk offset = 1663255445504 Couldn't map the block 626309926912 btrfs: volumes.c:1020: btrfs_num_copies: Assertion `!(ce-start logical || ce-start + ce-size logical)' failed. Aborted (core dumped) Strange enough, we don't find any chunks during scanning process. And seems this is unrecoverable ~_~ Wang, Any thoughts? On 28 July 2013 08:17, Wang Shilong wangshilong1...@gmail.com wrote: Hello, It seems Btrfs Chunk Tree is damaged, so you can not mount Btrfs filesystem any more. However, you can try the latest Btrfs-progs, Miao Xie implements chunk tree recover function. The url is: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git you can try it: btrfs chunk-recover -v dev This is Time-consuming, because it will scan the whole disk. And also, please catch output of processing(this is helpful to us if the recovery fails, -v option enable this). Thanks, Wang -- 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
Re: Recovering from btrfs error Couldn't read chunk root.
Unrecoverable? I know i cant mount and have access but my data are still there intact ( as i was using them till the reboot) i shouldn't be able to extract/recover them to another disc? With any magic command without mounting? Any other solutions? http://bpaste.net/show/118112/ On 29 July 2013 15:06, Wang Shilong wangshilong1...@gmail.com wrote: 在 2013-7-29，上午2:12，Kyriakos kyriakosbrastia...@gmail.com 写道： Just tried it as you said with the -v option enabled This is my output: http://bpaste.net/show/118112/ This is a *long* email, and seems that btrfs list refuse it. Device extent: devid = 1, start = 1667558801408, len = 1073741824, chunk offset = 1663255445504 Couldn't map the block 626309926912 btrfs: volumes.c:1020: btrfs_num_copies: Assertion `!(ce-start logical || ce-start + ce-size logical)' failed. Aborted (core dumped) Strange enough, we don't find any chunks during scanning process. And seems this is unrecoverable ~_~ Wang, Any thoughts? On 28 July 2013 08:17, Wang Shilong wangshilong1...@gmail.com wrote: Hello, It seems Btrfs Chunk Tree is damaged, so you can not mount Btrfs filesystem any more. However, you can try the latest Btrfs-progs, Miao Xie implements chunk tree recover function. The url is: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git you can try it: btrfs chunk-recover -v dev This is Time-consuming, because it will scan the whole disk. And also, please catch output of processing(this is helpful to us if the recovery fails, -v option enable this). Thanks, Wang -- 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
Recovering from btrfs error Couldn't read chunk root.
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 devid1 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/Kyriosbtrfs defaults,compress=lzo01 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
Re: Recovering from btrfs error Couldn't read chunk root.
Hello, It seems Btrfs Chunk Tree is damaged, so you can not mount Btrfs filesystem any more. However, you can try the latest Btrfs-progs, Miao Xie implements chunk tree recover function. The url is: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git you can try it: btrfs chunk-recover -v dev This is Time-consuming, because it will scan the whole disk. And also, please catch output of processing(this is helpful to us if the recovery fails, -v option enable this). Thanks, Wang -- 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
