All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Kastl <kastl@b1-systems.de>
To: linux-btrfs@vger.kernel.org
Cc: Qu Wenruo <quwenruo.btrfs@gmx.com>
Subject: Re: 'btrfs rescue' command (recommended by btrfs check) fails on old BTRFS RAID1 on (currently) openSUSE Leap 15.3
Date: Sun, 24 Apr 2022 11:10:26 +0200	[thread overview]
Message-ID: <53dabec5-14de-ed6f-1ef9-a300b96333a6@b1-systems.de> (raw)
In-Reply-To: <21dd5ba9-8dc0-7792-d5f4-4cd1ea91d75e@gmx.com>


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

Hi Qu,

On 24.04.22 at 01:07 Qu Wenruo wrote:

> No need to run btrfs check on each device.
> 
> Btrfs check will assemble the array automatically (just like kernel),
> and check the fs on all involved devices.
> Thus no need to run the same check on all devices.

OK, good to know. That saves half the time :-)

>> The output of the check is below. The TL;DR was that I should run 'btrfs
>> rescue fix-device-size' to fix a "minor" issue.
>>
>> Unfortunately, running this command fails:
>>
>>> root dumbo:/root # btrfs rescue fix-device-size /dev/sdc1
>>> Unable to find block group for 0
>>> Unable to find block group for 0
>>> Unable to find block group for 0
> 
> This is an unique error message, which can only be triggered when
> btrfs-progs failed to find a block group with enough free space.

So would resizing the filesystem (to 8GiB) workaround this "limitation", so 
afterwards it could properly fix the device size?

>>> btrfs unable to find ref byte nr 2959295381504 parent 0 root 3  owner
>>> 1 offset 0
>>> transaction.c:168: btrfs_commit_transaction: BUG_ON `ret` triggered,
>>> value -5
> 
> So at least no damage done to the good and innocent (but a little old) fs.

Puuuh, nice to hear that. :-)

>> So, my question is what I should do:
>>
>> Do I need to run another command to fix this issue?
> 
> Not really.
> 
> But if you want to really remove the warning, please update btrfs-progs
> first, to the latest stable version (v5.16.2), and try again.

I'll have a look if I can easily install a newer version of btrfsprogs on this 
machine.

> The involved progs, v4.19 is a little old, and IIRC we had some ENOSPC
> related fixed in progs, thus if above problem a bug caused false ENOSPC,
> it should be fixed now.

If I can install a newer version, I'll let you know if the bug disappears.

> You can ignore it for now.
> It's not a big deal and kernel can handle it without problem.

That's good.

>> Should I copy all of the data to another disk, and create a new BTRFS
>> RAID1 from scratch? (Which of course I would like to avoid, if possible...)
> 
> Definitely no.

Perfect.

Thanks for your reply! Have a nice day.

Kind Regards,
Johannes

-- 
Johannes Kastl
Linux Consultant & Trainer
Tel.: +49 (0) 151 2372 5802
Mail: kastl@b1-systems.de

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg
http://www.b1-systems.de
GF: Ralph Dehner
Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

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

  reply	other threads:[~2022-04-24  9:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-23 18:39 'btrfs rescue' command (recommended by btrfs check) fails on old BTRFS RAID1 on (currently) openSUSE Leap 15.3 Johannes Kastl
2022-04-23 23:07 ` Qu Wenruo
2022-04-24  9:10   ` Johannes Kastl [this message]
2022-04-24  9:21     ` Qu Wenruo
2022-05-18 10:38       ` Johannes Kastl
2022-05-18 10:59         ` Qu Wenruo
2022-05-20 15:14           ` Johannes Kastl
2022-05-20 20:21             ` Johannes Kastl
2022-05-21  1:10               ` Qu Wenruo
2022-05-24  7:44                 ` Johannes Kastl

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=53dabec5-14de-ed6f-1ef9-a300b96333a6@b1-systems.de \
    --to=kastl@b1-systems.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.