Re: Recovering from btrfs error Couldn't read chunk root.

2013-07-29 Thread Kyriakos
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.

2013-07-27 Thread Kyriakos
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