1 |
On Wednesday 05 September 2007, Walter Dnes wrote: |
2 |
> On Tue, Sep 04, 2007 at 10:45:15AM +0200, Alan McKinnon wrote |
3 |
> |
4 |
> > You will always have a pretty good idea how much space / needs, it |
5 |
> > contains /bin, /sbin, /etc, /root and /lib. Unless oyu are in the |
6 |
> > habit of storing stuff in /root, 500M is plenty. So put / on a |
7 |
> > regular partition, everything else in LVM and your initramfs |
8 |
> > worries go away. |
9 |
> |
10 |
> s/LVM/a partition using the rest of the hard drive/ |
11 |
|
12 |
I disagree with your entire approach. |
13 |
|
14 |
You are saying that you do not want to have to deal with LVM so your |
15 |
solution is to create one ginormous partition, stick everything on it |
16 |
and --bind mount directories from there to /usr, /var, etc. Sonow you |
17 |
have pieces of one big file system scattered all over your directory |
18 |
tree. |
19 |
|
20 |
What have you gained? Nothing that I can see, so you are going to have |
21 |
to explain this in detail so we can all understand why you are even |
22 |
starting this at all. |
23 |
|
24 |
From where I sit, you have gained nothing at all over one big filesystem |
25 |
mounted at /. You do not have the benfits of separate filesystems, you |
26 |
do not have the flexibility of LVM, you do not have the safety of |
27 |
separate mount points, you do not have the ability to mount various |
28 |
parts of the file system with different options. In fact, you have gone |
29 |
through several layers of symlinks to come back to the same place. |
30 |
|
31 |
How is this better than a 500G filesystem mounted at /? |
32 |
> |
33 |
> This is how I started the whole thread. |
34 |
> |
35 |
> > The only thing you need worry about is where are you going to get a |
36 |
> > decent howto that explains the concepts. You are dealing with three |
37 |
> > layers of stuff on top of physical partitions and some docs out |
38 |
> > there are ... confusing. Once you get the picture fully, it's as |
39 |
> > easy pie and makes perfect sense. |
40 |
> |
41 |
> Remove the LVM layer and things become even easier. |
42 |
|
43 |
Now I absolutely insist that you explain your reasoning and stop making |
44 |
assertions without backing them up. Give reasons, examples and numbers |
45 |
please. |
46 |
|
47 |
> > Really, LVM is the answer to all those prayers you have been |
48 |
> > sending up to $DEITY for years :-) |
49 |
> |
50 |
> With few exceptions, it's an answer looking for a problem. |
51 |
|
52 |
Again, back this up please. If you assert that LVM is complex, then I |
53 |
will agree with you. Because guess what? kernels are complex, software |
54 |
is the most complex machine we humans have ever designed and admining a |
55 |
box IS rocket science. But if you say that LVM is useless without |
56 |
giving actual examples, then I'm afraid I'm going to have to call BS on |
57 |
that one. |
58 |
|
59 |
Tell you what, I'll go first: |
60 |
|
61 |
1. What exactly are the few exceptions where LVM is not an answer |
62 |
looking for a problem, and actually is valid? Seeing as there are so |
63 |
few of them according to you, you should be able to rattle them off in |
64 |
a quick reply while asleep. |
65 |
|
66 |
2. Please explain in detail how you will create a 4TB file system |
67 |
without LVM. This is NOT an edge case, this is a very real situation |
68 |
that occurs in data centres daily. |
69 |
|
70 |
3. Take your proposal and explain to me in detail how you will prevent a |
71 |
backdoor or trojan from installing and executing scripts in /tmp |
72 |
and /var. Considering the massive problem that Windows has caused the |
73 |
world through an inability to do this, I would say this is a very |
74 |
important thing to be able to. |
75 |
|
76 |
alan |
77 |
|
78 |
|
79 |
-- |
80 |
Optimists say the glass is half full, |
81 |
Pessimists say the glass is half empty, |
82 |
Developers say wtf is the glass twice as big as it needs to be? |
83 |
|
84 |
Alan McKinnon |
85 |
alan at linuxholdings dot co dot za |
86 |
+27 82, double three seven, one nine three five |
87 |
-- |
88 |
gentoo-user@g.o mailing list |