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