All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pepie 34 <pepie34@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: Endless mount and backpointer mismatch
Date: Mon, 27 Jan 2020 22:59:33 +0100	[thread overview]
Message-ID: <46459688-6aed-7ec5-0bdd-97ff76fc13cb@gmail.com> (raw)
In-Reply-To: <CAJCQCtShdXA2SRkHvfRAS8EVLRRzCmJ3HA-Ynk=uOEc+9XD7iQ@mail.gmail.com>

Le 27/01/2020 à 22:48, Chris Murphy a écrit :
> On Mon, Jan 27, 2020 at 2:20 PM Pepie 34 <pepie34@gmail.com> wrote:
>> Dear BTRFS community,
>>
>> I've a raid 1 setup on two luks encrypted drives for 4 years that serves
>> me as btrbk backup target from an other computer.
>> There is a lot of ro snaptshots on it.
>>
>> I've mistakenly launched a balance on it which was extremely slow and
>> tried to cancelled it.
>> After two days of cancelling without results, I decided to power off the
>> computer.
>>
>> After the reboot, even with the skip_balance mount option, the mounting
>> is endless, no error in the kernel message and it never mounts.
>>
>> What I have done so far:
>> - mount the volume with the ro option (fast to mount, data OK).
>> - scrub in ro mode, no error found
>> - btrfs check
>> In the extent check  there is plenty of errors like this :
>> =>
>> ref mismatch on [9404816285696 32768] extent item 6, found 5
>>
>> incorrect local backref count on 9404816285696 parent 5712684302336
>> owner 0 offset 0 found 0 wanted 1 back 0x55f371ee1ad0
>> backref disk bytenr does not match extent record, bytenr=9404816285696,
>> ref bytenr=0
>> backpointer mismatch on [9404816285696 32768]
>> <=
>> No errors in other checks, though checking "quota groups" is very slow.
>>
>> What should I do ? btrfs check --repair ?
>> btrfs check --init-extent-tree ?
>> btrfs --clear-space-cache ?
> None of the above.
>
> What kernel version and btrfs-progs? Newer kernels should have better
> performance with quota enabled and many snapshots, even though I think
> that combination is still not advised for performance reasons. Older
> kernel might have a known bug related to the behavior you're
> experiencing, but we need to know the versions.
>
>
>
Kernel : 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)
x86_64 GNU/Linux
btrfs-progs: 4.20.1-2

I'm on debian buster.

Note that I don't really care about perf now, I mainly want to mount r/w
my volume.
With the same setup raid1 / luks  / quota, it was fast to mount and use
before the failed balancing.
(mount took about 2s... )
Now it is not mounting at all (except with ro)

Best regards,

Pepie 34


  reply	other threads:[~2020-01-27 21:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-27 21:20 Endless mount and backpointer mismatch Pepie 34
2020-01-27 21:48 ` Chris Murphy
2020-01-27 21:59   ` Pepie 34 [this message]
2020-01-28  1:23 ` Qu Wenruo
2020-01-28 17:32   ` Pepie 34
2020-02-05 12:50     ` Pepie 34

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=46459688-6aed-7ec5-0bdd-97ff76fc13cb@gmail.com \
    --to=pepie34@gmail.com \
    --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 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.