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

Goffredo Baroncelli
2012-06-21T05:47:34Z

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

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