linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Patrick Dijkgraaf <bolderbast@duckstad.net>, linux-btrfs@vger.kernel.org
Subject: Re: Need help: super_total_bytes mismatch with fs_devices total_rw_bytes
Date: Sun, 25 Aug 2019 21:36:58 +0800	[thread overview]
Message-ID: <f1725975-9a05-e26c-db70-ae2295fff4ab@gmx.com> (raw)
In-Reply-To: <2c681f5fd6ea3d8bc764416bad7da1f6f0665347.camel@duckstad.net>


[-- Attachment #1.1: Type: text/plain, Size: 3700 bytes --]



On 2019/8/25 下午2:41, Patrick Dijkgraaf wrote:
> Hi Qu,
> 
> At the end of my first initial post, I mentioned that I finally was
> able to mount the volume using:
> 
> mount -o usebackuproot,ro /dev/sdh2 /mnt/data
> 
> The chunk tree and super blocks dumps were taken after that.
> 
> Now I noticed that I was able to mount the volume without special
> options (same kernel version). YAY! ☺
> Could it be that the "usebackuproot,ro" mount options already fixed the
> issue?

Nope. It should be something wrong with the kernel code verifying the
total devices space.
As long as all your later mount is using ro, and no log tree replay
happened, the fs should not be modified.
It may be a race, but anyway, your on-disk data is completely valid, so
as long as your kernel is doing something correct, it should mount the fs.

Thanks,
Qu

> 
> Cheers,
> Patrick
> 
> 
> On Sat, 2019-08-24 at 21:24 +0800, Qu Wenruo wrote:
>> On 2019/8/24 下午8:05, Patrick Dijkgraaf wrote:
>>> Thanks for the quick reply!
>>> See responses inline.
>>>
>>> On Sat, 2019-08-24 at 19:01 +0800, Qu Wenruo wrote:
>>>> On 2019/8/24 下午2:48, Patrick Dijkgraaf wrote:
>>>>> Hi all,
>>>>>
>>>>> My server hung this morning, and I had to hard-reset is. I did
>>>>> not
>>>>> apply any updates. After the reboot, my FS won't mount:
>>>>>
>>>>> [Sat Aug 24 08:16:31 2019] BTRFS error (device sde2):
>>>>> super_total_bytes
>>>>> 92017957797888 mismatch with fs_devices total_rw_bytes
>>>>> 184035915595776
>>>>> [Sat Aug 24 08:16:31 2019] BTRFS error (device sde2): failed to
>>>>> read
>>>>> chunk tree: -22
>>>>> [Sat Aug 24 08:16:31 2019] BTRFS error (device sde2):
>>>>> open_ctree
>>>>> failed
>>>>>
>>>>> However, running btrfs rescue shows:
>>>>> root@cornelis ~]# btrfs rescue fix-device-size /dev/sdh2
>>>>> No device size related problem found
>>>>
>>>> That's strange.
>>>>
>>>> Would you please dump the chunk tree and super blocks?
>>>> # btrfs ins dump-super -fFa /dev/sdh2
>>>
>>> See: 
>>> https://pastebin.com/f5Wn15sx
>>>
>>
>> Did a quick calculation, from your fi show result, it's 83.72TiB,
>> thus
>> the super total_bytes is correct.
>>
>> It's the kernel doing incorrect calculation for its
>> fs_devices->total_rw_bytes.
>>
>> This matches the output of dump-super. No wonder why btrfs-progs
>> refuse
>> to fix.
>>>> # btrfs ins dump-tree -t chunk /dev/sdh2
>>>
>>> This output is too large for pastebin. The output is
>>> viewable/downloadable here: 
>>> https://kwek.duckstad.net/tree.txt
>>>
>>
>> This also proves your chunk tree is CORRECT!
>> The sum of all devices is 92017957797888, which matches with super
>> block.
>> [...]
>>>> The simplest way to fix it is to just update the
>>>
>>> Nice teaser! 😉 What should I update?
>>
>> Sorry, I meant to say just update the "superblock", but it turns out,
>> it's something wrong with your kernel. Probably some old bug we fixed
>> before.
>>
>> Would you try to use latest ARCH kernel from an Archiso to try to
>> mount
>> it RO (just to be safe)?
>>
>> I checked latest v5.3-rc kernels, haven't found an obvious problem
>> with
>> the fs_devices->total_rw_bytes update routines.
>>
>> So it may be an old bug which is already fixed.
>>
>> Thanks,
>> Qu
>>
>>>> Thanks,
>>>> Qu
>>>>> Other info:
>>>>> [root@cornelis ~]# uname -r
>>>>> 4.18.16-arch1-1-ARCH
>>>>>
>>>>> I was able to mount is using:
>>>>> [root@cornelis ~]# mount -o usebackuproot,ro /dev/sdh2
>>>>> /mnt/data
>>>>>
>>>>> Now updating my backup, but I REALLY hope to get this fixed on
>>>>> the
>>>>> production server!
>>>>>
>>>
>>>
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

      reply	other threads:[~2019-08-25 13:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-24  6:48 Need help: super_total_bytes mismatch with fs_devices total_rw_bytes Patrick Dijkgraaf
2019-08-24 11:01 ` Qu Wenruo
2019-08-24 12:05   ` Patrick Dijkgraaf
2019-08-24 13:24     ` Qu Wenruo
2019-08-25  6:41       ` Patrick Dijkgraaf
2019-08-25 13:36         ` Qu Wenruo [this message]

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=f1725975-9a05-e26c-db70-ae2295fff4ab@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=bolderbast@duckstad.net \
    --cc=linux-btrfs@vger.kernel.org \
    /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).