R: Re: Subvolumes and /proc/self/mountinfo
HI all,
Quoted 9 lines
----Messaggio originale----
Da: [email protected]
Data: 20/06/2012 5.22
A: "cwillu"<[email protected]>
Cc: <[email protected]>, <[email protected]>
Ogg: Re: Subvolumes and/proc/self/mountinfo
Quoted 5 lines
The concept of what is the "root" and what is the "path" is straightforward for lesser filesystems: the root of the filesystem is defined by the root inode, and the path is a unique sequence of directories from that root. Note that this is completely independent of how the filesystem was mounted when the boot loader was installed.
For the aim of the discussion, I would like to highlight a small difference between the path of the subvolume and the subvolume-id.
The latter is the specific subvolume, the former is a "functional" reference to this subvolume.
For example, in my root btrfs I have two two subvolumes: __active (the root filesystem of my system) and (__rollback the last "good" copy)
If I swap (via a rename) __active and __rollback, in the next boot my system uses a "good" copy of the root filesystem. This is a simple way to swap two subvolumes, without involving the boot logic
Instead if I had tracked the subvolume-id, to swap the root filesystem I would have update the boot logic.
I suspect that could exists other cases where it is preferable to track the subvolume-id instead the path. However what I would highlight it is the two ways aren't equal.
BR
G.Baroncelli
Quoted 5 lines · Goffredo Baroncelli
If I swap (via a rename)
__activeand__rollback, in the next boot my system uses a "good" copy of the root filesystem. This is a simple way to swap two subvolumes, without involving the boot logic
Quoted 7 lines
Instead if I had tracked the subvolume-id, to swap the root filesystem I would have update the boot logic.
I suspect that could exists other cases where it is preferable to track the subvolume-id instead the path. However what I would highlight it is the two ways aren't equal.
Yes. The question here is what makes sense for the low-level part of a bootloader (Syslinux in this case) to use, and it sounds like you have some experience here that would be highly useful to have.
The thing to keep in mind here is that the low level bootloader code *must* match what is installed in the boot block (functionally another part of the bootloader), or all hell will break loose. I think that means that relying on the subvolume ID makes more sense. To upgrade the bootloader, invoke the bootloader installer at the end of the update; that will repoint *everything*, which is rather nice.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 18 lines · H. Peter Anvin
Quoted 5 lines · Goffredo Baroncelli
If I swap (via a rename)
__activeand__rollback, in the next boot my system uses a "good" copy of the root filesystem. This is a simple way to swap two subvolumes, without involving the boot logicQuoted 7 lines
Instead if I had tracked the subvolume-id, to swap the root filesystem I would have update the boot logic.
I suspect that could exists other cases where it is preferable to track the subvolume-id instead the path. However what I would highlight it is the two ways aren't equal.
Yes. The question here is what makes sense for the low-level part of a bootloader (Syslinux in this case) to use, and it sounds like you have some experience here that would be highly useful to have.
Quoted 6 lines
The thing to keep in mind here is that the low level bootloader code *must* match what is installed in the boot block (functionally another part of the bootloader), or all hell will break loose. I think that means that relying on the subvolume ID makes more sense. To upgrade the bootloader, invoke the bootloader installer at the end of the update; that will repoint *everything*, which is rather nice.
At the first I tough that having the /boot separate could be a good thing. Unfortunately /boot contains both the bootloader code and the kernel image. The kernel image should be in sync with the contents of /lib/modules/....
This is the tricky point. If I handle /boot inside the filesystem submodule a de-sync between the bootloader code and the boot sector could happens. In I handle /boot as separate subvolume/filesystem a de-sync between the kernel image and the modules could happens.
Anyway, from a bootloader POV I think that /boot should be handle separately (or as filesystem or as subvolume identified by specific ID). The best could be move the kernel in the same subvolume as /lib/modules, so a switch of the subvolume as root filesystem would be coherent.
GB
Quoted 3 lines
-hpa
Quoted 11 lines · Goffredo Baroncelli
At the first I tough that having the /boot separate could be a good thing. Unfortunately /boot contains both the bootloader code and the kernel image. The kernel image should be in sync with the contents of
/lib/modules/....This is the tricky point. If I handle /boot inside the filesystem submodule a de-sync between the bootloader code and the boot sector could happens. In I handle /boot as separate subvolume/filesystem a de-sync between the kernel image and the modules could happens.
Quoted 5 lines
Anyway, from a bootloader POV I think that /boot should be handle separately (or as filesystem or as subvolume identified by specific ID). The best could be move the kernel in the same subvolume as
/lib/modules, so a switch of the subvolume as root filesystem would be coherent.
You're not really answering the question. "The best could be move the
kernel in the same subvolume as /lib/modules" isn't really going to happen... the whole *point* of /boot is that /boot contains everything needed to get to the point of kernel initialization.
So, sorry, you're out to sea here...
-hpa
HI,
Quoted 18 lines · H. Peter Anvin
Quoted 11 lines · Goffredo Baroncelli
At the first I tough that having the /boot separate could be a good thing. Unfortunately /boot contains both the bootloader code and the kernel image. The kernel image should be in sync with the contents of
/lib/modules/....This is the tricky point. If I handle /boot inside the filesystem submodule a de-sync between the bootloader code and the boot sector could happens. In I handle /boot as separate subvolume/filesystem a de-sync between the kernel image and the modules could happens.
Quoted 5 lines
Anyway, from a bootloader POV I think that /boot should be handle separately (or as filesystem or as subvolume identified by specific ID). The best could be move the kernel in the same subvolume as
/lib/modules, so a switch of the subvolume as root filesystem would be coherent.
Quoted 4 lines
You're not really answering the question. "The best could be move the
kernel in the same subvolume as/lib/modules" isn't really going to happen... the whole *point* of /boot is that /boot contains everything needed to get to the point of kernel initialization.
??
Am not saying that we *should* move the kernel away from /boot. I am only saying that having the kernel near /lib/modules *has* some advantages.
Few year ago there are some gains to have a separate /boot (ah, the time when the bios were unable to address the bigger disk), where there are the minimum things to bootstrap the system.
Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ? de facto standard ? historical reasons ? Nothing wrong here; but also the idea to moving the kernel under /lib/modules is not so wrong.
Quoted 1 line
So, sorry, you're out to sea here...
True, the sea is far away from my house :-)
Quoted 5 lines
-hpa
.
Hallo, Goffredo,
Du meintest am 20.06.12:
[...]
Quoted 8 lines
Am not saying that we *should* move the kernel away from /boot. I am only saying that having the kernel near
/lib/modules*has* some advantages.Few year ago there are some gains to have a separate /boot (ah, the time when the bios were unable to address the bigger disk), where there are the minimum things to bootstrap the system.
Quoted 5 lines
Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ?
Where is the big problem?
I use separate subdirectories for different kernels, p.e. "/boot/ 2.6.38.4" or "/boot/3.3.4" or "/boot/3.3.4-big". And these subdirs contain (p.e.) ".config", "vmlinuz", "initrd", "System.map".
It's a very clear design. No incredibly long filenames.
Viele Gruesse!
Helmut
Quoted 1 line · Helmut Hullen
Hallo, Goffredo,
Hi Helmut,
Quoted 19 lines
Du meintest am 20.06.12:
[...]
Quoted 8 lines
Am not saying that we *should* move the kernel away from /boot. I am only saying that having the kernel near
/lib/modules*has* some advantages.Few year ago there are some gains to have a separate /boot (ah, the time when the bios were unable to address the bigger disk), where there are the minimum things to bootstrap the system.
Quoted 5 lines
Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ?
Quoted 6 lines
Where is the big problem?
I use separate subdirectories for different kernels, p.e. "/boot/2.6.38.4" or "/boot/3.3.4" or "/boot/3.3.4-big". And these subdirs contain (p.e.) ".config", "vmlinuz", "initrd", "System.map".It's a very clear design. No incredibly long filenames.
Let me to explain my set-up.
My filesystem is in a subvolume; only /boot is in another filesystem. Every time I upgrade, remove, or change the system I take a snapshot, and regenerate the grub.cfg in order to take in account the new/old subvolume (a script generates a menu entry for every subvolume, so I am theoretically able to launch last kernel on every subvolume).
The point is that every snapshot could have a different set of kernel module, depending by the upgrade history. Often the latest kernel cannot boot^w work properly with old snapshot.
I am sure that there would be a lot of solutions, like:
- the script could be more smart, adding a grub menu entry only for valid kernel/subvolume pairs
- the /boot filesystem could have a subdir for each subvolume [...]
To me it seems that make sense to put the kernel near the /lib/modules
directories: the kernel is coupled with the modules, so why put them in different three ? Today the modern bootloader could address the full filesystem, so I don't see any reason to mandate the kernel to be under /boot.
May be that there is another more rationale solution to my problem. I am open to suggestions.
To me it was more traumatic the (re)moval of /sbin,/bin,/lib to /usr/sbin,/usr/sbin,/usr/lib :-) [*]
Thanks
G.Baroncelli
[*] http://fedoraproject.org/wiki/Features/UsrMove
Quoted 9 lines
Viele Gruesse!
Helmut
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.
Quoted 8 lines · Goffredo Baroncelli
Am not saying that we *should* move the kernel away from /boot. I am only saying that having the kernel near
/lib/modules*has* some advantages.Few year ago there are some gains to have a separate /boot (ah, the time when the bios were unable to address the bigger disk), where there are the minimum things to bootstrap the system.
There still is (in fact this exact problem has made a comeback, as there are plenty of BIOSes which have bugs above the 2 TB mark); however, there are also issues with RAID (firmware often cannot address all the devices in the system -- and no, that isn't ancient history, I have a system exactly like that that I bought last year), remote boot media (your / might be on an iSCSI device, or even a network filesystem!) and all kinds of situations like that.
The bottom line is that /boot is what the bootloader needs to be able to address, whereas / can wait until the kernel has device drivers. That is a *HUGE* difference.
Quoted 7 lines
Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ? de facto standard ? historical reasons ? Nothing wrong here; but also the idea to moving the kernel under
/lib/modulesis not so wrong.
No, it is completely, totally and very very seriously wrong.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.
Quoted 18 lines · H. Peter Anvin
Quoted 8 lines · Goffredo Baroncelli
Am not saying that we *should* move the kernel away from /boot. I am only saying that having the kernel near
/lib/modules*has* some advantages.Few year ago there are some gains to have a separate /boot (ah, the time when the bios were unable to address the bigger disk), where there are the minimum things to bootstrap the system.
There still is (in fact this exact problem has made a comeback, as there are plenty of BIOSes which have bugs above the 2 TB mark); however, there are also issues with RAID (firmware often cannot address all the devices in the system -- and no, that isn't ancient history, I have a system exactly like that that I bought last year), remote boot media (your / might be on an iSCSI device, or even a network filesystem!) and all kinds of situations like that.
Quoted 3 lines
The bottom line is that /boot is what the bootloader needs to be able to address, whereas / can wait until the kernel has device drivers. That is a *HUGE* difference
This leads to have a separately /boot filesystem. In this case I agree with you: make sense that the kernel is near the bootloader files.
But if /boot has to be in a separate filesystem, which is the point to support btrfs at all ? Does make sense to support only a subset of btrfs features ?
Quoted 10 lines
Quoted 8 lines
Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ? de facto standard ? historical reasons ? Nothing wrong here; but also the idea to moving the kernel under
/lib/modulesis not so wrong.No, it is completely, totally and very very seriously wrong.
When a bootloader (and the bioses) will be able to address the whole diskS, this will change.. Not now
Quoted 3 lines
-hpa
Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:
Quoted 12 lines
Quoted 12 lines
Quoted 9 lines
Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ? de facto standard ? historical reasons ? Nothing wrong here; but also the idea to moving the kernel under
/lib/modulesis not so wrong.
Quoted 4 lines
Quoted 1 line
No, it is completely, totally and very very seriously wrong.
When a bootloader (and the bioses) will be able to address the whole diskS, this will change.. Not now
Why not the other way around? /boot/modules-3.4 or so.
But either way, these are different discussions. H. Peter´s question was, if I understood correctly, whether to use subvolid or path?
I tend to lean towards subvolid.
Ciao,
Signature · 2 lines
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Quoted 15 lines · Martin Steigerwald
Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:
Quoted 14 lines
Quoted 13 lines
Quoted 9 lines
Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ? de facto standard ? historical reasons ? Nothing wrong here; but also the idea to moving the kernel under
/lib/modulesis not so wrong.No, it is completely, totally and very very seriously wrong.
Quoted 8 lines
Quoted 2 lines
When a bootloader (and the bioses) will be able to address the whole diskS, this will change.. Not now
Why not the other way around?
/boot/modules-3.4or so.But either way, these are different discussions. H. Peter´s question was, if I understood correctly, whether to use subvolid or path?
For which ?
If you want to point the bootloader subvolume (where the 2nd stage relies), I suggest subvolid=. If you need to point to the kernel (bzImage/initrd) *for my setup* it would be useful to use the path. Unfortunately these two requirements are in contrast.
Quoted 4 lines
I tend to lean towards subvolid.
Ciao,
Ciao
Goffredo
Quoted 8 lines · Goffredo Baroncelli
This leads to have a separately /boot filesystem. In this case I agree with you: make sense that the kernel is near the bootloader files.
But if /boot has to be in a separate filesystem, which is the point to support btrfs at all ? Does make sense to support only a subset of btrfs features ?
Yes, and that's another good reason for /boot: btrfs supports that kind of policy (e.g. "no compression or encryption in this subtree.")
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Now we have the possibility to move the kernel near the modules, and this could lead some interesting possibility: think about different linux installations, with an own kernel version and an own modules version; what are the reasons to put together under /boot different kernel which potential conflicting names ? de facto standard ? historical reasons ? Nothing wrong here; but also the idea to moving the kernel under
/lib/modulesis not so wrong.
Quoted 5 lines
Quoted 1 line
No, it is completely, totally and very very seriously wrong.
When a bootloader (and the bioses) will be able to address the whole diskS, this will change.. Not now
People have said that for 15 years. The reality is that firmware will always be behind the curve, and *that's ok*, we just need to deal with it.
-hpa
Quoted 6 lines · H. Peter Anvin
Quoted 4 lines
But if /boot has to be in a separate filesystem, which is the point to
Quoted 3 lines
support btrfs at all ? Does make sense to support only a subset of btrfs features ?
Yes, and that's another good reason for /boot: btrfs supports that kind of policy (e.g. "no compression or encryption in this subtree.")
But what about large disk ? Syslinux is able to handle large disk ? Or it uses BIOS interrupt?
Quoted 10 lines · Goffredo Baroncelli
Quoted 6 lines · H. Peter Anvin
Quoted 4 lines
But if /boot has to be in a separate filesystem, which is the point to
Quoted 3 lines
support btrfs at all ? Does make sense to support only a subset of btrfs features ?
Yes, and that's another good reason for /boot: btrfs supports that kind of policy (e.g. "no compression or encryption in this subtree.")
But what about large disk ? Syslinux is able to handle large disk ? Or it uses BIOS interrupt?
It uses the firmware.. how well the firmware can handle large disks is another matter.
-hpa
Signature · 2 lines
H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.