All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Martin Steigerwald <martin@lichtvoll.de>, linux-btrfs@vger.kernel.org
Subject: Re: external harddisk: bogus corrupt leaf error?
Date: Tue, 22 Sep 2020 10:14:34 +0800	[thread overview]
Message-ID: <6e508d1c-32fe-1162-f905-2e57022f8dc6@gmx.com> (raw)
In-Reply-To: <f0fd36fd-3ffa-ff02-e5d9-265fc64e38f3@gmx.com>


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



On 2020/9/22 上午7:48, Qu Wenruo wrote:
> 
> 
> On 2020/9/21 下午7:46, Martin Steigerwald wrote:
>> Qu Wenruo - 21.09.20, 13:14:05 CEST:
>>>>> For the root cause, it should be some older kernel creating the
>>>>> wrong
>>>>> root item size.
>>>>> I can't find the commit but it should be pretty old, as after v5.4
>>>>> we
>>>>> have mandatory write time tree checks, which will reject such write
>>>>> directly.
>>>>
>>>> So eventually I would have to backup the disk and create FS from
>>>> scratch to get rid of the error? Or can I, even if its no subvolume
>>>> involved, find the item affected, copy it somewhere else and then
>>>> write it to the disk again?
>>> That's the theory.
>>>
>>> We can easily rebuild that data reloc tree, since it should be empty
>>> if balance is not running.
>>>
>>> But we don't have it ready at hand in btrfs-progs...
>>>
>>> So you may either want to wait until some quick dirty fixer arrives,
>>> or can start backup right now.
>>> All the data/files shouldn't be affected at all.
>>
>> Hmmm, do you have an idea if and when such a quick dirty fixer would be 
>> available?
> 
> If you need, I guess in 24 hours.

Here you go:
https://github.com/adam900710/btrfs-progs/tree/dirty_fix

You need to compile the btrfs-progs (in fact, you need to compile
btrfs-corrupt-block).
Then execute:
# ./btrfs-corrupt-block -X <device>

It should solve the problem.
If nothing is output, and no crash, then the repair is done.
Or you will see a crash with calltrace, and your on-disk data is untouched.


The root problem turns out to be a false alert.

It's possible to have an old root item, which is smaller than current
root_item.
In that case, current kernel can handle it without problem.

I'll fix the problem in the kernel too to prevent further false alerts.

Thanks,
Qu

> 
>>
>> Also, is it still safe to write to the filesystem? I looked at the disk, 
>> cause I wanted to move some large files over to it to free up some space 
>> on my laptop's internal SSDs.
> 
> Yes. If you want to be extra safe, just don't utilize balance until it's
> fixed.
> 
> Thanks,
> Qu
> 
>>
>> If its still safe to write to the filesystem, I may just wait. I will 
>> refresh the backup of the disk anyway. But if its not safe to write to 
>> it anymore, I would redo the filesystem from scratch. Would give the 
>> added benefit of having everything zstd compressed and I could also go 
>> for XXHASH or what one of the faster of the new checksum algorithms was.
>>
>> Best,
>>
> 


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

  reply	other threads:[~2020-09-22  2:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-21  9:29 external harddisk: bogus corrupt leaf error? Martin Steigerwald
2020-09-21 10:09 ` Qu Wenruo
2020-09-21 10:30   ` Martin Steigerwald
2020-09-21 11:14     ` Qu Wenruo
2020-09-21 11:46       ` Martin Steigerwald
2020-09-21 22:26         ` Chris Murphy
2020-09-21 23:48         ` Qu Wenruo
2020-09-22  2:14           ` Qu Wenruo [this message]
2020-09-22  8:40             ` Martin Steigerwald
2020-09-22  8:44               ` Qu Wenruo

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=6e508d1c-32fe-1162-f905-2e57022f8dc6@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=martin@lichtvoll.de \
    /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.