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:
>>
>> 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
>
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Linux NFS]
[Linux NILFS]
[Linux USB Devel]
[Video for Linux]
[Linux Audio Users]
[Photo]
[Yosemite News]
[Yosemite Photos]
[Free Online Dating]
[Linux Kernel]
[Linux SCSI]
[XFree86]