From: Anand Jain <Anand.Jain@oracle.com>
To: zcoffey@mytech42.com
Cc: linux-btrfs@vger.kernel.org
Subject: Re: RAID1 fails to recover chunk tree
Date: Thu, 30 Oct 2014 11:33:07 +0800 [thread overview]
Message-ID: <5451B173.6040206@oracle.com> (raw)
In-Reply-To: <545140D4.4060404@gmail.com>
just notice your case is different from others seen/working on.
in your the layout has issue. its not about the raid. sorry.
try: mount -o recovery,ro
On 10/30/2014 03:32 AM, Zack Coffey wrote:
>
> $ 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
>
> --
> 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-30 3:29 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
2014-10-30 3:33 ` Anand Jain [this message]
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=5451B173.6040206@oracle.com \
--to=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.