HI all,>----Messaggio originale---- >Da: hpa@zytor.com >Data: 20/06/2012 5.22 >A: "cwillu"<cwillu@cwillu.com> >Cc: <helmut@hullen.de>, <linux-btrfs@vger.kernel.org> >Ogg: Re: Subvolumes and /proc/self/mountinfo >> >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 -- 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
On 06/20/2012 05:02 AM, Goffredo Baroncelli <kreijack@libero.it> wrote:> > 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. >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 -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don''t speak on their behalf. -- 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
On 06/20/2012 05:37 PM, H. Peter Anvin wrote:> On 06/20/2012 05:02 AM, Goffredo Baroncelli <kreijack@libero.it> wrote: >> >> 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. >> > > 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.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> > -hpa >-- 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
On 06/20/2012 09:34 AM, Goffredo Baroncelli wrote:> > 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. >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 -- 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
HI, On 06/20/2012 07:41 PM, H. Peter Anvin wrote:> On 06/20/2012 09:34 AM, Goffredo Baroncelli wrote: >> >> 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. >> > > 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.> So, sorry, you''re out to sea here...True, the sea is far away from my house :-)> > -hpa > > . >-- 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
Hallo, Goffredo, Du meintest am 20.06.12: [...]> 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 ?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 -- 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
On 06/20/2012 09:15 PM, Helmut Hullen wrote:> Hallo, Goffredo,Hi Helmut,> > Du meintest am 20.06.12: > > [...] > >> 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 ? > > 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> > Viele Gruesse! > Helmut > -- > 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 > . >-- 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
On 06/20/2012 11:06 AM, Goffredo Baroncelli wrote:> > 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.> 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.No, it is completely, totally and very very seriously wrong. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don''t speak on their behalf. -- 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
On 06/20/2012 11:49 PM, H. Peter Anvin wrote:> On 06/20/2012 11:06 AM, Goffredo Baroncelli wrote: >> >> 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* differenceThis 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 ?> >> 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. > > 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> > -hpa >-- 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
Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli:> > > > > >> 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. > > > > > > > > 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 nowWhy 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, -- Martin ''Helios'' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 -- 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
On 06/20/2012 10:47 PM, Goffredo Baroncelli wrote:> > 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.")>> >>> 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. >> >> 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 -- 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
On 06/21/2012 01:46 PM, Martin Steigerwald wrote:> Am Donnerstag, 21. Juni 2012 schrieb Goffredo Baroncelli: >>> >>> >>>> 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. >>> >>> >>> >>> 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? >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.> I tend to lean towards subvolid.> > Ciao,Ciao Goffredo -- 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
On 06/21/2012 03:38 PM, H. Peter Anvin wrote:>> 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.")But what about large disk ? Syslinux is able to handle large disk ? Or it uses BIOS interrupt? -- 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
On 06/21/2012 10:05 AM, Goffredo Baroncelli wrote:> On 06/21/2012 03:38 PM, H. Peter Anvin wrote: >>> 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.") > > 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 -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don''t speak on their behalf. -- 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