All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Steven Davies <btrfs-list@steev.me.uk>,
	linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: Device missing with RAID1 on boot - observations
Date: Tue, 6 Apr 2021 08:32:12 +0800	[thread overview]
Message-ID: <b2a00975-4bde-11ba-d0e4-1e15ec3afb4c@gmx.com> (raw)
In-Reply-To: <b9c77dc7-8c72-7c64-9ce8-bcb4555de0c0@steev.me.uk>



On 2021/4/5 下午11:18, Steven Davies wrote:
> Kernel: 5.11.8 vanilla, btrfs-progs 5.11.1
>
> I booted a box with a root btrfs raid1 across two devices,
> /dev/nvme0n1p2 (devid 2) and /dev/sda2 (devid 3). For whatever reason
> during the initrd stage, btrfs device scan was unable to see the NVMe
> device and mounted the rootfs degraded after multiple retries as I had
> designed in the init script.

It looks more like a problem in your initramfs environment.

The more possible cause is, your initramfs only has driver for SATA
disks, but no NVME modules.

You may try to include nvme module in your initramfs to see if that
solves the problem.

Thanks,
Qu

>
> Once booted apparently the kernel was able to see nvme0n1p2 again (with
> no intervention from me) and btrfs device usage / btrfs filesystem show
> did not report any missing devices. btrfs scrub reported that devid 2
> was unwriteable but the scrub completed successfully on devid 3 with no
> errors. New block groups for data and metadata were being created as
> single on devid 3.
>
> I balanced with -dconvert=single -mconvert=dup which moved all block
> groups to devid 3 and completed successfully; there was nothing
> remaining on devid 2 so I removed the device from the filesystem and
> re-added it as devid 4. Once I'd balanced the filesystem back to
> -dconvert=raid1 -mconvert=raid1 everything was back to normal.
>
> My main observation was that it was very hard to notice that there was
> an issue. Yes, I'd purposefully mounted as degraded, but there was no
> indication from the btrfs tools as to why new block groups were only
> being created as single on one device: nothing was marked as missing or
> unwriteable. Is this behavour expected? How can a device be unwriteable
> but not marked as missing?
>
> Was my course of action to correct the issue correct - is there a better
> way to re-sync a raid1 device which has temporarily been removed?
>
> (Afterwards I realised what caused the issue - missing libraries in the
> initrd - and I can reproduce it if necessary.)
>

      reply	other threads:[~2021-04-06  0:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-05 15:18 Device missing with RAID1 on boot - observations Steven Davies
2021-04-06  0:32 ` 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=b2a00975-4bde-11ba-d0e4-1e15ec3afb4c@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=btrfs-list@steev.me.uk \
    --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.