linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* find_mount_root() issue
@ 2014-08-31  7:37 Remco Hosman - Yerf IT.nl
  2014-08-31  9:41 ` Duncan
  0 siblings, 1 reply; 4+ messages in thread
From: Remco Hosman - Yerf IT.nl @ 2014-08-31  7:37 UTC (permalink / raw)
  To: linux-btrfs

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


Hope this helps,
Remco

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: find_mount_root() issue
  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
  0 siblings, 1 reply; 4+ messages in thread
From: Duncan @ 2014-08-31  9:41 UTC (permalink / raw)
  To: linux-btrfs

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*.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: find_mount_root() issue
  2014-08-31  9:41 ` Duncan
@ 2014-09-02  1:33   ` Qu Wenruo
  2014-09-02  1:39     ` Qu Wenruo
  0 siblings, 1 reply; 4+ messages in thread
From: Qu Wenruo @ 2014-09-02  1:33 UTC (permalink / raw)
  To: Duncan, remco; +Cc: linux-btrfs


-------- 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: find_mount_root() issue
  2014-09-02  1:33   ` Qu Wenruo
@ 2014-09-02  1:39     ` Qu Wenruo
  0 siblings, 0 replies; 4+ messages in thread
From: Qu Wenruo @ 2014-09-02  1:39 UTC (permalink / raw)
  To: Duncan, remco; +Cc: linux-btrfs


-------- Original Message --------
Subject: Re: find_mount_root() issue
From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Duncan <1i5t5.duncan@cox.net>, <remco@yerf-it.nl>
Date: 2014年09月02日 09:33
>
> -------- 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.
Oh, I suddenly recognized that the returned mount_point path is the same,
so just the not_btrfs makes it return 1....

So "<=" fix is OK. :P

To Remco, would you please send the patch to maillist?

Thanks,
Qu
>
> Thanks,
> Qu
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2014-09-02  1:39 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
2014-09-02  1:39     ` Qu Wenruo

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).