All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: linux-btrfs@vger.kernel.org, Qu Wenruo <quwenruo.btrfs@gmx.com>
Subject: Re: external harddisk: bogus corrupt leaf error?
Date: Mon, 21 Sep 2020 13:46:13 +0200	[thread overview]
Message-ID: <8020498.oVlb7o6SH1@merkaba> (raw)
In-Reply-To: <8d2987f8-e27e-eedb-164f-b05d74ad8f3b@gmx.com>

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?

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.

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,
-- 
Martin



  reply	other threads:[~2020-09-21 11:46 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 [this message]
2020-09-21 22:26         ` Chris Murphy
2020-09-21 23:48         ` Qu Wenruo
2020-09-22  2:14           ` Qu Wenruo
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=8020498.oVlb7o6SH1@merkaba \
    --to=martin@lichtvoll.de \
    --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 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.