1 |
Daiajo Tibdixious posted on Tue, 05 Jun 2012 09:52:15 +1000 as excerpted: |
2 |
|
3 |
> I forgot about the dependent packages. I might forget about separating |
4 |
> system & world & just backup all the binpkg's |
5 |
|
6 |
FWIW, that's pretty much what I do here (but with all packages together, |
7 |
not separate @system/@world). I use FEATURES=binpkg and have a separate |
8 |
binpkgs partition, then a second partition of the same size that I mkfs |
9 |
and copy everything from the first one to, every so often. |
10 |
|
11 |
Binpkg partition size is now 8 gigs. 3 gigs works if you clean out all |
12 |
the old binpkgs regularly (eclean), and I ran 4 gigs for awhile, but I |
13 |
run the kde betas (as of yesterday, 4.8.80 aka 4.9-beta1) and like to |
14 |
keep plenty of room for the last upstream-stable I had (4.8.3) plus the |
15 |
last and current betas, and found 4 gig a bit tight for that, so when I |
16 |
upgraded disks, I doubled the size to 8 gigs, tho 6 probably would have |
17 |
done as well. |
18 |
|
19 |
It doesn't matter so much on a packages partition as the files are large, |
20 |
but FWIW I run reiserfs with tail-packing on, as I can't see wasting all |
21 |
the partial blocks, and reiserfs has been quite stable for me (even thru |
22 |
hardware issues) since data=ordered mode was introduced back in 2.6.16 or |
23 |
so. It makes a BIG difference on the sources (both gentoo/overlay trees |
24 |
and kernel, plus ccache) partition, tho. (I'm looking forward to the |
25 |
still experimental btrfs, but tried it recently and it's not solid yet, |
26 |
particularly in the case of hard-reboots, etc. Lost files is NOT my |
27 |
thing, and missing parts of files or having files replaced with the |
28 |
contents of other files is worse, hard reboot or no hard reboot, so it |
29 |
was back to the tried and tested, for me.) |
30 |
|
31 |
FWIW, I use the dup-partition thing for everything. Put it on raid1 |
32 |
(again, looking forward to btrfs raid1 mode) if you have it, so losing a |
33 |
disk won't kill things either, and you're set for either loss of disk |
34 |
(raid1) or fat-fingering something (backup partition). Three copies of |
35 |
root (working and two backups), in case both the working and a backup go |
36 |
down while I'm doing maintenance, two of everything else. |
37 |
|
38 |
(If you have multiple disks in md/raid1 or similar, making /boot a normal |
39 |
partition or a raid1 of half the drives if more than two, with its backup |
40 |
a similar partition on the other drive(s), works well. Select which one |
41 |
you want to boot in bios, and upgrade one at a time then test before |
42 |
upgrading the other, when doing bootloader upgrades. That works well for |
43 |
git kernels too, only upgrading the backup /boot with full kernel |
44 |
releases, keeping the git kernels on the working /boot. If just a single |
45 |
disk, than obviously more than one /boot doesn't help that much since the |
46 |
initial sector bootloader can only point to one /boot.) |
47 |
|
48 |
-- |
49 |
Duncan - List replies preferred. No HTML msgs. |
50 |
"Every nonfree program has a lord, a master -- |
51 |
and if you use the program, he is your master." Richard Stallman |