From: Zack Coffey <tech42.clickwir@gmail.com>
To: Anand Jain <Anand.Jain@oracle.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: RAID1 fails to recover chunk tree
Date: Wed, 29 Oct 2014 15:32:36 -0400 [thread overview]
Message-ID: <545140D4.4060404@gmail.com> (raw)
In-Reply-To: <5450651C.3010104@oracle.com>
$ sudo mount -o degraded,ro /dev/sdd1 /asdf
mount: wrong fs type, bad option, bad superblock on /dev/sdd1,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
$ dmesg | tail
[524718.760792] BTRFS info (device sdd1): allowing degraded mounts
[524718.760800] BTRFS info (device sdd1): disk space caching is enabled
[524718.762087] BTRFS: failed to read chunk root on sdd1
[524718.776524] BTRFS: open_ctree failed
$ uname -a
Linux mach 3.17.1-52.g5c4d099-desktop #1 SMP PREEMPT Sat Oct 18 23:36:23
UTC 2014 (5c4d099) x86_64 x86_64 x86_64 GNU/Linux
$ btrfs --version
Btrfs v3.16.2+20141003
On 10/28/2014 11:55 PM, Anand Jain wrote:
>
>
> 'mount degraded,ro'
> see if there is any non-zero non-raid1 group profile.
>
>
>
> On 10/29/14 04:32, Zack Coffey wrote:
>> Revisit of a previous issue. Setup a single 640GB drive with BTRFS and
>> compression. This was not a system drive, just a place to put random
>> junk.
>>
>> Made a RAID1 with another drive of just the metadata. Was in
>> that state for less than 12 hours-ish, removed the second drive and
>> now cannot get to any data on the original drive. Data remained single
>> while only metadata was RAID1.
>>
>> Single drive btrfs was made on Ubuntu with kernel 3.13.0 and tools
>> 3.12.
>>
>> $ sudo mount -o degraded /dev/sdc1 /media/Data/
>> mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
>> missing codepage or helper program, or other error
>> In some cases useful info is found in syslog - try
>> dmesg | tail or so
>>
>> $ dmesg | tail
>> [45353.869448] KBD BUG in
>> ../../../../../../../../
>> drivers/2d/lnx/fgl/drm/kernel/
>> gal.c at line:
>> 304!
>> [45353.901511] KBD BUG in
>> ../../../../../../../../
>> drivers/2d/lnx/fgl/drm/kernel/gal.c at line:
>> 304!
>> [45353.901666] KBD BUG in
>> ../../../../../../../../drivers/2d/lnx/fgl/drm/kernel/gal.c at line:
>> 304!
>> [45354.148488] KBD BUG in
>> ../../../../../../../../drivers/2d/lnx/fgl/drm/kernel/gal.c at line:
>> 304!
>> [45354.148573] KBD BUG in
>> ../../../../../../../../drivers/2d/lnx/fgl/drm/kernel/gal.c at line:
>> 304!
>> [46241.155350] btrfs: device fsid bd78815a-802b-43e2-8387-fc6ab4237d67
>> devid 1 transid 60944 /dev/sdc1
>> [46241.155923] btrfs: allowing degraded mounts
>> [46241.155927] btrfs: disk space caching is enabled
>> [46241.159436] btrfs: failed to read chunk root on sdc1
>> [46241.177815] btrfs: open_ctree failed
>>
>> $ btrfs-show-super /dev/sdc1
>> superblock: bytenr=65536, device=/dev/sdc1
>> ------------------------------
>> ---------------------------
>> csum 0x93bcb1b5 [match]
>> bytenr 65536
>> flags 0x1
>> magic _BHRfS_M [match]
>> fsid bd78815a-802b-43e2-8387-fc6ab4237d67
>> label
>> generation 60944
>> root 909586694144
>> sys_array_size 97
>> chunk_root_generation 60938
>> root_level 1
>> chunk_root 911673917440
>> chunk_root_level 1
>> log_root 0
>> log_root_transid 0
>> log_root_level 0
>> total_bytes 1115871535104
>> bytes_used 321833435136
>> sectorsize 4096
>> nodesize 4096
>> leafsize 4096
>> stripesize 4096
>> root_dir 6
>> num_devices 2
>> compat_flags 0x0
>> compat_ro_flags 0x0
>> incompat_flags 0x9
>> csum_type 0
>> csum_size 4
>> cache_generation 60944
>> uuid_tree_generation 60944
>> dev_item.uuid d82b2027-17b6-4513-a86d-9227a42d7ed1
>> dev_item.fsid bd78815a-802b-43e2-8387-fc6ab4237d67 [match]
>> dev_item.type 0
>> dev_item.total_bytes 615763673088
>> dev_item.bytes_used 324270030848
>> dev_item.io_align 4096
>> dev_item.io_width 4096
>> dev_item.sector_size 4096
>> dev_item.devid 1
>> dev_item.dev_group 0
>> dev_item.seek_speed 0
>> dev_item.bandwidth 0
>> dev_item.generation 0
>>
>>
>> $ sudo btrfs device add -f /dev/sdh1 /dev/sdc1
>> ERROR: error adding the device '/dev/sdh1' - Inappropriate ioctl for
>> device
>>
>> $ sudo btrfs device delete missing /dev/sdc1
>> ERROR: error removing the device 'missing' - Inappropriate ioctl for
>> device
>>
>> $ sudo mount -o degraded,defaults,compress=lzo /dev/sdc1 /media/Data/
>> mount: wrong fs type, bad option, bad superblock on /dev/sdc1,
>> missing codepage or helper program, or other error
>> In some cases useful info is found in syslog - try
>> dmesg | tail or so
>>
>> $ dmesg | tail
>> [106991.655384] btrfs: device fsid
>> bd78815a-802b-43e2-8387-fc6ab4237d67 devid 1 transid 60944 /dev/sdc1
>> [106991.665066] btrfs: device fsid
>> bd78815a-802b-43e2-8387-fc6ab4237d67 devid 1 transid 60944 /dev/sdc1
>> [107019.954397] btrfs: device fsid
>> bd78815a-802b-43e2-8387-fc6ab4237d67 devid 1 transid 60944 /dev/sdc1
>> [107019.962009] btrfs: device fsid
>> bd78815a-802b-43e2-8387-fc6ab4237d67 devid 1 transid 60944 /dev/sdc1
>> [107070.124927] btrfs: device fsid
>> bd78815a-802b-43e2-8387-fc6ab4237d67 devid 1 transid 60944 /dev/sdc1
>> [107070.126475] btrfs: allowing degraded mounts
>> [107070.126479] btrfs: use lzo compression
>> [107070.126480] btrfs: disk space caching is enabled
>> [107070.127254] btrfs: failed to read chunk root on sdc1
>> [107070.142983] btrfs: open_ctree failed
>>
>> $ sudo btrfs rescue super-recover -v /dev/sdc1
>> All Devices:
>> Device: id = 1, name = /dev/sdc1
>>
>> Before Recovering:
>> [All good supers]:
>> device name = /dev/sdc1
>> superblock bytenr = 65536
>>
>> device name = /dev/sdc1
>> superblock bytenr = 67108864
>>
>> device name = /dev/sdc1
>> superblock bytenr = 274877906944
>>
>> [All bad supers]:
>>
>> All supers are valid, no need to recover
>>
>> $ btrfs rescue chunk-recover -v /dev/sdc1
>> <<snipped>>
>> Chunk: start = 860100755456, len = 1073741824, type = 1, num_stripes = 1
>> Stripes list:
>> [ 0] Stripe: devid = 1, offset = 26877100032
>> No block group.
>> No device extent.
>> Chunk: start = 861174497280, len = 1073741824, type = 1,
>> num_stripes = 1
>> Stripes list:
>> [ 0] Stripe: devid = 1, offset = 27950841856
>> No block group.
>> No device extent.
>>
>> Total Chunks: 333
>> Heathy: 305
>> Bad: 28
>>
>> Orphan Block Groups:
>> Block Group: start = 872985657344, len = 1073741824, flag = 4
>> Block Group: start = 911673917440, len = 33554432, flag = 2
>> Block Group: start = 911707471872, len = 1073741824, flag = 4
>>
>> Orphan Device Extents:
>> Device extent: devid = 2, start = 2182086656, len = 33554432, chunk
>> offset = 911673917440
>> Device extent: devid = 2, start = 2215641088, len = 1073741824,
>> chunk offset = 911707471872
>> Fail to recover the chunk tree.
>> <</snipped>>
>>
>> Here's the full snipped paste: http://pastebin.com/fEm3Gup7
>>
>> Now I'm on openSUSE Tumbleweed (kernel 3.17). Still get the same
>> result from 'chunk-recover'. There's 305 healthy chunks, is there
>> anyway to recover that data and forget about the bad ones?
>>
>> A good portion of the data on that drive was backed up, but some
>> wasn't. My fault, I've learned. Can I get anything back from that
>> drive?
>>
>> Thanks
>> --
>> 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
next prev parent reply other threads:[~2014-10-29 19:32 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-28 20:32 RAID1 fails to recover chunk tree Zack Coffey
2014-10-29 3:55 ` Anand Jain
2014-10-29 19:32 ` Zack Coffey [this message]
2014-10-30 3:33 ` Anand Jain
2014-10-29 22:26 ` Robert White
2014-10-29 23:07 ` Robert White
2014-10-30 13:30 ` Zack Coffey
2014-10-30 15:23 ` Zygo Blaxell
2014-10-30 18:04 ` Chris Murphy
2014-10-31 1:27 ` Duncan
2014-10-31 2:09 ` Chris Murphy
2014-11-02 4:26 ` Robert White
2014-11-02 8:48 ` Roman Mamedov
2014-11-02 11:08 ` Robert White
2014-11-03 6:52 ` Duncan
2014-11-03 8:00 ` Duncan
2014-10-31 8:35 ` Robert White
2014-10-31 12:15 ` Zack Coffey
2014-11-02 4:19 ` Robert White
-- strict thread matches above, loose matches on Subject: below --
2014-10-28 20:18 Zack Coffey
2014-10-27 19:01 Zack Coffey
2014-10-15 21:09 Zack Coffey
2014-10-15 15:42 Zack Coffey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=545140D4.4060404@gmail.com \
--to=tech42.clickwir@gmail.com \
--cc=Anand.Jain@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=zcoffey@mytech42.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox