From: Johannes Hirte <johannes.hirte@datenkhaos.de>
To: Duncan <1i5t5.duncan@cox.net>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount
Date: Mon, 15 Sep 2014 19:13:58 +0200 [thread overview]
Message-ID: <20140915191358.373f7e3a@datenkhaos.de> (raw)
In-Reply-To: <pan$654be$d6b1d475$33035c3b$be242b8b@cox.net>
On Sun, 14 Sep 2014 00:45:49 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> Johannes Hirte posted on Sat, 13 Sep 2014 23:23:20 +0200 as excerpted:
>
> > On Sat, 13 Sep 2014 19:55:25 +0200 Johannes Hirte
> > <johannes.hirte@datenkhaos.de> wrote:
> >
> >> On Sat, 13 Sep 2014 13:36:37 +0800 Anand Jain
> >> <Anand.Jain@oracle.com> wrote:
> >>
> >>> The quickest workaround for you will be to try to match
> >>> the device path as in the btrfs fi show -m </mnt> output to your
> >>> probably fstab/mnttab entry.
> >>
> >> Doesn't work here. I don't even get a path with the affected
> >> kernels. I'll get:
> >>
> >> Label: none uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
> >> Total devices 1 FS bytes used 270.10GiB
> >> *** Some devices missing
> >>
> >> Btrfs v3.16
> >>
> >> with a working kernel:
> >>
> >> Label: none uuid: 02edbd6b-f044-4800-b21e-ca8982c2c2e5
> >> Total devices 1 FS bytes used 270.10GiB
> >> devid 1 size 293.89GiB used 289.06GiB path /dev/sda1
> >>
> >> Btrfs v3.16
>
> >> And now I was able to reproduce on a second machine. The main
> >> difference between the affected and the unaffected systems is
> >> initramfs. On the affected systems, I don't use one. On the working
> >> systems, the rootfs is mounted via initramfs before. I'll test, if
> >> an initramfs will solve the issue. Seems likely, cause if I put
> >> the disk of an affected system into a working system and mount it
> >> there, everything works.
> >
> > Of course, with the initramfs it works.
>
> I see a btrfs device scan in the initramfs script. What happens if
> you simply run btrfs device scan manually, before doing btrfs
> filesystem show?
>
> I'm guessing that'll fix it.
Not tested, but I doubt it will fix it. In this initramfs it is a
leftover from a time, when the system was multi-device. On two other
systems, initramfs works without the scan. Additionally I can put the
affected HDD from the laptop and put it into/on another system, that is
affected without initramfs. I can mount it there without any scan
before. But I'm not 100% sure if udev takes responsibility for scanning
here.
regards,
Johannes
next prev parent reply other threads:[~2014-09-15 17:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-10 22:22 "Btrfs: device_list_add() should not update list when mounted" breaks subvol mount Johannes Hirte
2014-09-10 23:26 ` Anand Jain
2014-09-11 2:37 ` Anand Jain
2014-09-12 20:43 ` xavier.gnata
2014-09-13 5:36 ` Anand Jain
2014-09-13 17:55 ` Johannes Hirte
2014-09-13 21:23 ` Johannes Hirte
2014-09-14 0:45 ` Duncan
2014-09-15 17:13 ` Johannes Hirte [this message]
2014-09-15 12:32 ` Anand Jain
2014-09-15 17:14 ` Johannes Hirte
2014-09-15 17:39 ` Anand Jain
2014-09-15 22:17 ` Johannes Hirte
2014-09-16 21:55 ` Anand Jain
2014-09-17 8:49 ` Anand Jain
2014-09-14 11:12 ` xavier.gnata
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=20140915191358.373f7e3a@datenkhaos.de \
--to=johannes.hirte@datenkhaos.de \
--cc=1i5t5.duncan@cox.net \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).