1 |
On Friday, December 21, 2012 09:57:25 AM Michał Górny wrote: |
2 |
> On Fri, 21 Dec 2012 09:10:22 +0100 |
3 |
> |
4 |
> "J. Roeleveld" <joost@××××××××.org> wrote: |
5 |
> > On Thursday, December 20, 2012 09:31:36 AM Michał Górny wrote: |
6 |
> > > On Thu, 20 Dec 2012 00:27:26 +0100 |
7 |
> > > |
8 |
> > > "J. Roeleveld" <joost@××××××××.org> wrote: |
9 |
> > > > On Wednesday, December 19, 2012 09:13:28 AM Greg KH wrote: |
10 |
> > > > > On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote: |
11 |
> > > > > > On Mon, December 17, 2012 22:31, Greg KH wrote: |
12 |
> > > > > > > On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote: |
13 |
> > > > > > >> Olav Vitters <olav@×××××××.nl> wrote: |
14 |
> > > > > > >> >On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote: |
15 |
> > > > > > >> >> As I said in an earlier email, Lennart Poettering claims |
16 |
> > > > > > >> >> that it |
17 |
> > > > > > >> >> does |
18 |
> > > > > > >> >> not work. We are discussing some of the things necessary to |
19 |
> > > > > > >> >> make |
20 |
> > > > > > >> >> it |
21 |
> > > > > > >> > |
22 |
> > > > > > >> >work. |
23 |
> > > > > > >> > |
24 |
> > > > > > >> >Just to repeat: |
25 |
> > > > > > >> >In this thread it was claimed that a separate /usr is not |
26 |
> > > > > > >> >supported by |
27 |
> > > > > > >> >systemd/udev. |
28 |
> > > > > > >> > |
29 |
> > > > > > >> >A case which works with latest systemd on various |
30 |
> > > > > > >> >distributions. I |
31 |
> > > > > > >> >checked with upstream (not Lennart), and they confirmed it |
32 |
> > > > > > >> >works. |
33 |
> > > > > > >> >I |
34 |
> > > > > > >> >can |
35 |
> > > > > > >> >wait for Lennart to say the same, but really not needed. |
36 |
> > > > > > >> > |
37 |
> > > > > > >> >I assume this will again turn into a "but I meant something |
38 |
> > > > > > >> >else". |
39 |
> > > > > > >> |
40 |
> > > > > > >> Olav. |
41 |
> > > > > > >> |
42 |
> > > > > > >> Lennart has stated that he considers a seperate /usr without |
43 |
> > > > > > >> init* |
44 |
> > > > > > >> broken. |
45 |
> > > > > > > |
46 |
> > > > > > > Yes, as do I, and so do a lot of other developers. |
47 |
> > > > > > |
48 |
> > > > > > It is only "broken", because upstream decided to move everything |
49 |
> > > > > > into |
50 |
> > > > > > /usr |
51 |
> > > > > > that was previously in /. |
52 |
> > > > > |
53 |
> > > > > No, not at all, please see the web page that describes, in detail, |
54 |
> > > > > the |
55 |
> > > > > problems that has been going on for quite some time now, with the |
56 |
> > > > > /usr |
57 |
> > > > > and / partitions and packages. |
58 |
> > > > > |
59 |
> > > > > http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken |
60 |
> > > > > |
61 |
> > > > > One good solution to this issue is to move everything into /usr, and |
62 |
> > > > > that's something that has wonderful benifits in the long run, and is |
63 |
> > > > > something that I expect all Linux distros to eventually implement. |
64 |
> > > > > Those that don't, will suffer because of it. |
65 |
> > > > > |
66 |
> > > > > Again, see the web page for why moving stuff into /usr is a good |
67 |
> > > > > idea |
68 |
> > > > > for the reasons behind this. |
69 |
> > |
70 |
> > http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge |
71 |
> > |
72 |
> > > > Example: /usr Network Share |
73 |
> > > > When /usr is on a network share, why not add a / on network as well? |
74 |
> > > > I have multiple systems and as they all have different uses, they all |
75 |
> > > > have |
76 |
> > > > different software installed. |
77 |
> > > > |
78 |
> > > > Example: Multiple Guest Operating Systems on the Same Host |
79 |
> > > > See answer to previous example. |
80 |
> > > > |
81 |
> > > > How many environments actually currently exist where a shared /usr is |
82 |
> > > > being |
83 |
> > > > used? |
84 |
> > > |
85 |
> > > Are you aware that these environments are actually one of the most |
86 |
> > > important reasons for moving everything to /usr? I don't know what |
87 |
> > > hackery you're using to keep the systems in sync and working but it is |
88 |
> > > braindead enough. |
89 |
> > |
90 |
> > An init* needs to be kept in sync with the rest of the system as well. As |
91 |
> > that is a compressed filesystem, it takes a lot more effort to keep that |
92 |
> > in sync in comparison to a "normal" filesystem. |
93 |
> > I consider having to write scripts to unpack, modify and repack an init* |
94 |
> > to be more hackery then to keep a bootable root-filesystem working that |
95 |
> > can mount all the filesystems needed for the whole environment. |
96 |
> > Anything needed to mount /usr, /var, /run (and any other part needed for |
97 |
> > the boot-process) should not be allowed to depend on anything in any of |
98 |
> > those directories prior to those being mountable. |
99 |
> > |
100 |
> > > The difference between keeping part of the system in rootfs |
101 |
> > > and initramfs is that you can discard initramfs after using it. It can |
102 |
> > > be anything which is enough to get the /usr mounted and system |
103 |
> > > starting. Files on rootfs *have* to be in sync with those on /usr |
104 |
> > > or you're getting random failures. |
105 |
> > |
106 |
> > The same is true for an init*. |
107 |
> > If an update of part of the OS leads to subtle changes in the filesystem |
108 |
> > where older versions can no longer properly access them, the init* is |
109 |
> > broken. |
110 |
> Just let me know when you have to maintain a lot of such systemd |
111 |
> and upgrade, say, glibc. Then maybe you'll understand. |
112 |
|
113 |
A shared /usr means I need to update ALL the systems at once. |
114 |
When /usr is not shared, I can update groups at a time. |
115 |
|
116 |
To save time, a shared filesystem containing binary packages can easily be |
117 |
used and this is what I use myself. |
118 |
I have one VM that is used to rebuild the packages when I want to do an update |
119 |
and the real host then simply uses the binary packages. |
120 |
The configuration items needed for emerge are synchronized between the build |
121 |
system and the actual server. |
122 |
|
123 |
The main reason why I would never share an OS filesystem between multiple |
124 |
systems is to avoid the situation where a failed upgrade takes down the entire |
125 |
environment. |
126 |
And a shared OS filesystem also introduces a very nice Single Point of |
127 |
Failure. What will happen when the NFS-server (or whatever is used) goes down |
128 |
for whatever reason? |
129 |
|
130 |
In other words, to make an environment that has a very nice single point of |
131 |
failure possible, existing working environments are classed as "broken". |
132 |
|
133 |
-- |
134 |
Joost |