All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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 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.