Re: R: Re: Subvolumes and /proc/self/mountinfo

On 06/20/2012 11:49 PM, H. Peter Anvin wrote:

On 06/20/2012 11:06 AM, Goffredo Baroncelli wrote:

quoted

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

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

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