From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Duncan <1i5t5.duncan@cox.net>, <remco@yerf-it.nl>
Cc: <linux-btrfs@vger.kernel.org>
Subject: Re: find_mount_root() issue
Date: Tue, 2 Sep 2014 09:33:03 +0800 [thread overview]
Message-ID: <54051E4F.1080102@cn.fujitsu.com> (raw)
In-Reply-To: <pan$abcad$cae3304e$722c055b$e8898249@cox.net>
-------- Original Message --------
Subject: Re: find_mount_root() issue
From: Duncan <1i5t5.duncan@cox.net>
To: <linux-btrfs@vger.kernel.org>
Date: 2014年08月31日 17:41
> Remco Hosman - Yerf IT.nl posted on Sun, 31 Aug 2014 09:37:38 +0200 as
> excerpted:
>
>> issue:
>> on my system i have 2 entries for /, one with the type ‘rootfs’ and a
>> 2nd one with the type ‘btrfs’. find_mount_root() uses the first one and
>> reports a fail.
>>
>> My change:
>> if (longest_matchlen < len) {
>> into:
>> if (longest_matchlen <= len) {
>>
>> i have not tested this, but in my understanding it will use the last
>> longest match instead of the first.
>>
>> I have no idea if this rootfs entry is normal nor if its always there
>> before the ‘proper’ one.
>>
>> These are the 2 entries in my mount list:
>> rootfs / rootfs rw 0 0
>> /dev/sda2 / btrfs rw,noatime,ssd,noacl,space_cache 0 0
> AFAIK that rootfs entry is the kernel's built-in initramfs that it
> automatically mounts, even if empty, before mounting your real-root.
>
> If you use an initramfs/initrd, the switch_root process normally hides/
> unmounts the initr*, but if you don't and the kernel is using its empty
> one, nothing hides/unmounts it, so it's still there after the normal / is
> mounted over top.
>
> At least, I always booted to root directly without an initr*, and always
> had a rootfs entry until relatively recently, presumably when I switched
> to a two-device btrfs real-rootfs, and had to create and use an initramfs
> to do so[1]. Now I don't have a rootfs entry any longer.
>
> ---
> [1] Initr* required for multi-device btrfs root: Btrfs has the device=
> mount option, which would normally be passed via a kernel-command-line
> rootflags= option to btrfs, that can be used with multi-device-
> filesystems in the absence of btrfs device scan. Unfortunately,
> rootflags=device= fails for some reason, or at least did last time I
> tried it, so the only way I can get a multi-device btrfs root to mount is
> to use an initr*.
>
Interesting, as mentioned by Duncan, the normal situation is that initr*
root should be hidden/unmounted.
But when things out of the normal track, like Remco's problem, current
find_mount_root will only use
the first longest match, any further match will be ignored.
So (longest_matchlen <= len) is OK for this case.
On the other hand, (longest_matchlen <= len) will fail under the
following situation:
/dev/sdb on /mnt/test type btrfs (rw,relatime,space_cache)
/dev/sdc on /mnt/test type ext4 (rw,relatime,data=ordered)
To fix the behavior , the correct fix seems to only return the mount
entry with all the following condition:
1) longgest match
2) fs type is btrfs
If I am wrong, please tell me.
Thanks,
Qu
next prev parent reply other threads:[~2014-09-02 1:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-31 7:37 find_mount_root() issue Remco Hosman - Yerf IT.nl
2014-08-31 9:41 ` Duncan
2014-09-02 1:33 ` Qu Wenruo [this message]
2014-09-02 1:39 ` 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=54051E4F.1080102@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
--cc=remco@yerf-it.nl \
/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.