1 |
On Tue, Mar 27, 2012 at 10:02 AM, Mike Edenfield <kutulu@××××××.org> wrote: |
2 |
|
3 |
[snip] |
4 |
|
5 |
> As you move more and more software off of /usr into / you start to realize |
6 |
> that the idea of "tiny partition that contains just what I need to boot and |
7 |
> mount /usr" is becoming "not so tiny" anymore. The distinction between what |
8 |
> is "boot" software versus "user" software gets less clear. Then it's just |
9 |
> question of how far you take this process before you reach your personal |
10 |
> threshold of questioning why you have two partitions at all. Whether you |
11 |
> reach that point or not depends on how complex your boot process is, what |
12 |
> you actually need running to boot, and how personally invested in a split |
13 |
> /usr you happen to be :) |
14 |
|
15 |
This extends directly by analogy to having binaries on /usr mounted on |
16 |
anything other than plain disk. Say you wanted to have / on LVM on |
17 |
RAID6. Now you don't have any choice but to move stuff from /usr/* to |
18 |
your initramfs, since the kernel isn't even going to automount your |
19 |
RAID for you if you're not using the 0.9 metadata format, and you've |
20 |
still got to cope with LVM. |
21 |
|
22 |
As you say, the boundary between user software and boot software grows |
23 |
less and less clear, and your *initramfs* grows bigger and bigger. How |
24 |
long will there remain *any point* to LVM or software RAID, once you |
25 |
have to preload the bulk of your operating system into RAM before you |
26 |
can access their contents? One shouldn't need an entire operating |
27 |
system preloaded into RAM before being able to access the current |
28 |
versions of anything. |
29 |
|
30 |
The *real* fun is going to start once you get daemons which happen to |
31 |
need to be launched while you're still in your initramfs stage, and |
32 |
then you need to restart those daemons as part of an update later in |
33 |
the system's uptime. That's going to be a fun one to solve. |
34 |
|
35 |
-- |
36 |
:wq |