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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Wang Shilong
2013-Jul-28 05:17 UTC
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wang Shilong
2013-Jul-29 12:06 UTC
Re: Recovering from btrfs error Couldn''t read chunk root.
在 2013-7-29，上午2:12，Kyriakos <kyriakosbrastianos@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 <wangshilong1991@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 <wangshilong1991@gmail.com> wrote:> > 在 2013-7-29，上午2:12，Kyriakos <kyriakosbrastianos@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 <wangshilong1991@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Wang Shilong
2013-Jul-30 13:32 UTC
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 <wangshilong1991@gmail.com> wrote: >> >> 在 2013-7-29，上午2:12，Kyriakos <kyriakosbrastianos@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 <wangshilong1991@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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html