1 |
On Mon, Jul 21, 2008 at 3:02 PM, Alan E. Davis <lngndvs@×××××.com> wrote: |
2 |
|
3 |
> Thank you for some thoughtful suggestions. |
4 |
> |
5 |
> I have just gotten a 500GB SATA drive, intending to back up all of my |
6 |
> data. What I fear most about LVM is the possibility of losing the |
7 |
> data somehow. I may be too yesterday, but I sense that ordinary |
8 |
> partitions (at least "ordinary" to me) will be more portable. I may |
9 |
> want to unpack my system, and carry my Drives with me. |
10 |
|
11 |
|
12 |
So consider this: Virtually any system you will use these days that can read |
13 |
ext2/3/reiser drives will also be able to use LVM volumes. If not, it can |
14 |
easily be gotten to do so (via modprobe) |
15 |
|
16 |
|
17 |
> I've been |
18 |
> trying to work around the same /home/USER directories for several |
19 |
> years. I have archived them from time to time when they have gotten |
20 |
> too crazy. And (correct me if I'm wrong) I've become some kind of |
21 |
> intimidated about using the same directory and username on a new |
22 |
> install, so I generally end up copying all the pieces over. |
23 |
|
24 |
|
25 |
nah, that's false paranoia. |
26 |
|
27 |
cp, scp, rsync, chown, chmod. Used i the right combinations, will fix any |
28 |
problems in this regard. They are just files after all. |
29 |
|
30 |
> |
31 |
> |
32 |
> Outside of this possibly irrational fear that LVM mayn't be portable, |
33 |
> I actually did delete an entire install once that was on LVM, but that |
34 |
> was due to my own ignorance. I am no less ignorant now, but if my |
35 |
> fears about portability can be allayed, I would be willing to try. |
36 |
> And learn. |
37 |
|
38 |
|
39 |
LVM is an old, old, old technology. Originally developed by IBM for their |
40 |
mainframes. It predates that absurb concoction called "partition tables". |
41 |
Apart from 640kB, that must rate as one of the worst screw-ups in computing |
42 |
ever... |
43 |
|
44 |
> |
45 |
> Be that as it may, I have just cleansed my 74GB 10000RPM drive, and |
46 |
> look forward to installing on this, and hanging various directories |
47 |
> off of this. Assuming, for now, I am only going to be using some |
48 |
> unexotic partitioning system, which partitions will be most |
49 |
> advantageously situated on this fast drive? I am thinking along |
50 |
> these lines: |
51 |
> |
52 |
> FAST PARTITION |
53 |
> / |
54 |
|
55 |
|
56 |
yes, keep this separate |
57 |
|
58 |
/boot |
59 |
|
60 |
|
61 |
good to keep this separate too |
62 |
|
63 |
/usr/bin |
64 |
> /usr/sbin |
65 |
> /usr/local/ |
66 |
|
67 |
|
68 |
No, this is simply thick. |
69 |
Maybe one could make a case for /usr/local, but /usr/bin and /usr/sbin were |
70 |
usually separate on Unix several decades ago *purely because* disks were |
71 |
small and it's a convenient way to split things up to fit on available |
72 |
disks. |
73 |
|
74 |
Just stick all of /usr on one volume and be done with it. You might want to |
75 |
move /usr/portage and perhaps /usr/portage onto their own filesystem, |
76 |
because those directories do have different usage patterns than everything |
77 |
else in /usr |
78 |
|
79 |
part of home with well-used files |
80 |
|
81 |
|
82 |
ALL of /home. |
83 |
|
84 |
Why split it up? You lose the very benefit of having /home separate - the |
85 |
ability to update the entire system and guarantee that you won't stuff up |
86 |
your personal files while doing it |
87 |
|
88 |
/tmp? |
89 |
|
90 |
|
91 |
/tmp benefits from being separate. If you have a lot of RAM, it really |
92 |
benefits from being tmpfs rather than disk-based |
93 |
|
94 |
I have a lot of ARCHIVED data that should be on a separate partition |
95 |
> and this could be slow. |
96 |
|
97 |
|
98 |
Good idea. It also lets you tar up an entire filesystem for backup purposes |
99 |
|
100 |
-- |
101 |
Alan McKinnon |
102 |
alan.mckinnon@×××××.com |