linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Roderick Johnstone <rmj@ast.cam.ac.uk>
To: Qu Wenruo <quwenruo.btrfs@gmx.com>, linux-btrfs@vger.kernel.org
Subject: Re: Broken filesystem
Date: Tue, 19 Feb 2019 12:42:24 +0000	[thread overview]
Message-ID: <fda02e91-aa41-0c9b-d25d-4a348e88e9f0@ast.cam.ac.uk> (raw)
In-Reply-To: <0d7012d4-0274-aa8b-1a49-9c269f3cfdf1@gmx.com>

On 19/02/2019 12:34, Qu Wenruo wrote:
> 
> 
> On 2019/2/19 下午6:24, Roderick Johnstone wrote:
>> Hi
>>
>> This is on Fedora 28:
>>
>> # uname -a
>> Linux mysystem.mydomain 4.20.7-100.fc28.x86_64 #1 SMP Wed Feb 6 19:17:09
>> UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
>>
>> # btrfs --version
>> btrfs-progs v4.17.1
>>
>> #   btrfs fi show
>> Label: none  uuid: 56d0171a-440d-47ff-ad0f-f7f97df31f7b
>>          Total devices 1 FS bytes used 7.39TiB
>>          devid    1 size 9.10TiB used 7.50TiB path /dev/md2
>>
>>
>> My btrfs filesystem is in a bad state after a partial disk failure on
>> the md device (raid 6 array) the file system was on.
>>
>> One of the disks had bad blocks, but instead of being ejected from the
>> array, the array hung up.
> 
> I'm a little interested why RAID6 hung up.

I'm not sure but I think it was due to the failure more of the hardware.

> 
>> After rebooting to regain access and remove
>> the bad disk I am in the following situation:
>>
>> # mount -t btrfs -o compress-force=zlib,noatime /dev/md2 /mnt/rmj
>> mount: /mnt/rmj: wrong fs type, bad option, bad superblock on /dev/md2,
>> missing codepage or helper program, or other error.
>> # dmesg
>> ...
>>    264.527647] BTRFS info (device md2): force zlib compression, level 3
>> [  264.955360] BTRFS error (device md2): parent transid verify failed on
>> 5568287064064 wanted 254988 found 94122
> 
> It's 99% some extent tree blocks get corrupted.
> 
>> [  264.964273] BTRFS error (device md2): open_ctree failed
>>
>> I can mount and access the filesystem with the usebackuproot option:
>>
>> # mount -t btrfs -o usebackuproot,compress-force=zlib,noatime /dev/md2
>> /mnt/rmj
>> [  307.542761] BTRFS info (device md2): trying to use backup root at
>> mount time
>> [  307.542768] BTRFS info (device md2): force zlib compression, level 3
>> [  307.570897] BTRFS error (device md2): parent transid verify failed on
>> 5568287064064 wanted 254988 found 94122
>> [  307.570979] BTRFS error (device md2): parent transid verify failed on
>> 5568287064064 wanted 254988 found 94122
>> [  431.167149] BTRFS info (device md2): checking UUID tree
>>
>> But later after a umount there are these messages.
>>
>> # umount /mnt/rmj
>> 2205.778998] BTRFS error (device md2): parent transid verify failed on
>> 5568276393984 wanted 254986 found 94117
>> [ 2205.779008] BTRFS: error (device md2) in __btrfs_free_extent:6831:
>> errno=-5 IO failure
>> [ 2205.779082] BTRFS info (device md2): forced readonly
>> [ 2205.779087] BTRFS: error (device md2) in btrfs_run_delayed_refs:2978:
>> errno=-5 IO failure
>> [ 2205.779192] BTRFS warning (device md2): btrfs_uuid_scan_kthread
>> failed -30
> Of course it's extent tree corrupted.
> 
>>
>> and a subsequent mount without the userbackuproot fails in the same way
>> as before.
>>
>> I have a copy of the important directories, but would like to be able to
>> repair the filesystem if possible,
> 
> You could mostly salvage the data, either use 'usebackuproot' mount
> option + RO mount or btrfs-restore.
> 
> For full rw recovery, I don't think there is a good tool right now.
> Extent tree repair is pretty trikcy, under most case, the only method is
> --init-extent-tree, but that functionality isn't tried by many users.
> And it only makes sense if all other trees are OK.
> 
> So in short, RW recovery is near impossible.
> 
>>
>> Any advise around repairing the filesystem would be appreciated.
> 
> It's better to salvage your data first and if you like adventure, try
> --init-extent-tree.
> If not, just rebuild the array.


ok, thanks.

Roderick
> 
> Thanks,
> Qu
> 
>>
>> Thanks.
>>
>> Roderick Johnstone
> 

  reply	other threads:[~2019-02-19 12:42 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-19 10:24 Broken filesystem Roderick Johnstone
2019-02-19 12:34 ` Qu Wenruo
2019-02-19 12:42   ` Roderick Johnstone [this message]
2020-01-25 11:34 Broken Filesystem Hendrik Friedel
2020-01-25 12:20 ` Qu Wenruo
     [not found]   ` <emeee471c5-e6f0-4503-8410-742b05f87305@ryzen>
2020-01-25 13:36     ` Qu Wenruo
2020-01-25 15:22 ` Hugo Mills
2020-01-25 19:46 ` Chris Murphy

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=fda02e91-aa41-0c9b-d25d-4a348e88e9f0@ast.cam.ac.uk \
    --to=rmj@ast.cam.ac.uk \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.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;
as well as URLs for NNTP newsgroup(s).