1 |
I'll skip the bits that were already dealt with. |
2 |
|
3 |
On Thu, Aug 6, 2015 at 5:19 AM, Peter Humphrey <peter@××××××××××××.uk> wrote: |
4 |
> |
5 |
> First, btrfs balance. I had no idea that was needed, so of course I didn't |
6 |
> include it in my attempts. Could that be why, on booting, the kernel couldn't |
7 |
> mount the file system? |
8 |
|
9 |
It isn't necessarily essential, but btrfs fi df /mnt/gentoo will show |
10 |
you that before the balance there are still some chunks in single mode |
11 |
- it seems like mkfs creates the first device and adds the second one, |
12 |
leaving some residual non-RAID chunks (that hopefully will never have |
13 |
data written to them). The balance of an empty filesystem is really |
14 |
fast and completely converts it to raid1, so I figured it would be |
15 |
cleaner to do it this way. I have no idea what happens if those |
16 |
single chunks remain and you degrade the array. |
17 |
|
18 |
> |
19 |
> Third, why do you do your kernel compiling in /var/tmp/linux? It seems like |
20 |
> extra work and I can't see a reason for it. |
21 |
|
22 |
I usually still do my compiling as root (though this isn't an ideal |
23 |
practice). I build in /var/tmp for a few reasons: |
24 |
|
25 |
1. It keeps my sources clean. All the output goes in /var/tmp. |
26 |
Every build is pristine, etc. |
27 |
2. /var/tmp is a tmpfs - so the build goes MUCH faster (only reads |
28 |
from my raid1 btrfs /usr/src, all writes go to tmpfs). Only the final |
29 |
built stuff has to be installed back (a fraction of total bytes |
30 |
written), and then you're reading from tmpfs and only writing to disk. |
31 |
Anytime you can avoid simultaneous read/writes from a disk things go |
32 |
much faster. Btrfs isn't exactly known for its speed at this point, |
33 |
especially for writes, so I try to avoid dumping junk on it. |
34 |
3. If you're using gentoo-sources they'll actually cleanly uninstall |
35 |
since they aren't messed with. |
36 |
|
37 |
(Thanks to all for the comments so far. They offer opportunities for |
38 |
testing/experimentation, and also indicate where more explanation will |
39 |
be helpful when I turn this into an article. And, hopefully, a few |
40 |
will already benefit in getting their btrfs systems working with these |
41 |
notes.) |
42 |
|
43 |
(My article should also have a warning at the top - btrfs is |
44 |
experimental so don't come to me if it eats your data and you didn't |
45 |
have backups. raid1 is fairly mature at this point but I tend to |
46 |
stick with mature but recent longterm kernels (indeed, I should |
47 |
probably use a 3.18 series kernel explicitly in the install, and not |
48 |
let it go with 4.0 though that at least is starting to mature).) |
49 |
|
50 |
-- |
51 |
Rich |