1 |
Am Wed, 7 May 2014 00:53:07 +0200 |
2 |
schrieb Marc Joliet <marcec@×××.de>: |
3 |
|
4 |
[...] |
5 |
> > This migration will occur in conjunction with a migration of / + /usr to a |
6 |
> > cheap SSD that I just bought (Crucial M500 120 GB). The overall plan is thus as |
7 |
> > follows: |
8 |
> > |
9 |
> > Replace |
10 |
> > |
11 |
> > /boot on /dev/md1 (EXT3, RAID 1) |
12 |
> > / (with assorted sub-directories, sans /usr) on /dev/md2 (EXT4, RAID 10) |
13 |
> > the rest on LVM on /dev/md3 (all LVs EXT4, RAID 10) |
14 |
> > |
15 |
> > with |
16 |
> > |
17 |
> > / + /boot + /usr + swapfile on the SSD (EXT4) |
18 |
> > the rest (/home, my media partitions) on a btrfs RAID 10 |
19 |
> |
20 |
> This part I think I will stick with. From what I've read so far, I wouldn't |
21 |
> trust my entire system to btrfs. Since "the rest" consists of stuff I either |
22 |
> automatically backup (using rsnapshot) or have multiple copies of, I should be |
23 |
> able to recover from a broken btrfs file system fairly easily. |
24 |
> |
25 |
> While I am unsure of my choice of RAID level (some comments on LWN.net claim |
26 |
> that the MD RAID 10 is more comparable to btrfs' RAID 1, which I will attempt to |
27 |
> verify myself beforehand). However, due to btrfs' live rebalancing feature, I |
28 |
> worry less about this. By the time I really need more space the RAID 5/6 code |
29 |
> (and maybe N-way mirroring) ought to be stable (or at least finished), or I |
30 |
> can switch to RAID 1 if I need the flexibility. |
31 |
> |
32 |
> [...] |
33 |
> > The reason why I would choose EXT4 for the SSD is that btrfs still lacks support |
34 |
> > for swap files and I worry about creating a swap partition on the SSD. Is that |
35 |
> > warranted, or will the wear-levelling of the SSD handle that just fine? Do swap |
36 |
> > partitions support SSDs specially? Also, does anyone know whether EXT4 goes |
37 |
> > beyond "merely" supporting TRIM? That is, the btrfs wiki advertises the |
38 |
> > following: |
39 |
> > |
40 |
> > "SSD (Flash storage) awareness (TRIM/Discard for reporting free blocks for |
41 |
> > reuse) and optimizations (e.g. avoiding unnecessary seek optimizations, |
42 |
> > sending writes in clusters, even if they are from unrelated files. This |
43 |
> > results in larger write operations and faster write throughput)" |
44 |
> > |
45 |
> > Does EXT4 also implement such optimisations for SSDs? |
46 |
> |
47 |
> I will also go ahead with this (despite the open questions), although I will |
48 |
> leave swap on the LVM for now. I think tonight (well, today) I "just" want to |
49 |
> get the SSD running. Furthermore, "btrfs convert" should be able to up-convert |
50 |
> it in the future once btrfs is "production ready" (both articles make a |
51 |
> guesstimate of about 1-2 years). |
52 |
> |
53 |
> I think I would also prefer running a few days from the SSD before converting |
54 |
> "the rest" to btrfs, which should be fairly simple at that point. |
55 |
|
56 |
Weeee, this part is done as of this morning! I am now successfully booting from |
57 |
the SSD with GRUB 2. |
58 |
|
59 |
So far I've noticed the following advantages: |
60 |
|
61 |
- RAID shutdown actually succeeds now (it never did before with / on a RAID 10). |
62 |
|
63 |
- It feels like my boot time was halved (not counting the BIOS and boot |
64 |
loader, though); logging into my desktop also feels much quicker now. After |
65 |
that, though, it feels like there are few noticeable advantages in everyday |
66 |
usage (I expect portage to become faster, though). Obviously these types of |
67 |
speed-ups are to be expected from an SSD, but it still feels worth mentioning. |
68 |
|
69 |
- GRUB 2 is so much nicer to use than legacy GRUB! Now every time I install a |
70 |
new kernel, I just run "grub2-mkconfig -o /boot/grub/grub.cfg" and reboot, |
71 |
and everything will just work! |
72 |
|
73 |
(I was already used to this on my work/uni laptop, so manually editing legacy |
74 |
GRUB's configuration files on my desktop always felt like a chore.) |
75 |
|
76 |
The whole procedure wasn't that hard, either (ordered slightly more logically |
77 |
than what I actually did): |
78 |
|
79 |
- "emerge grub:2" (I have it in parallel to legacy GRUB for now) |
80 |
- use gparted to create one large EXT4 boot partition on the SSD |
81 |
- boot to a systemrescuecd |
82 |
- "cp -a" the / + /usr + ... to the SSD (yes, I should have used rsync) |
83 |
- copy the kernel images to /boot on the SSD |
84 |
- chroot into the SSD (following the Gentoo handbook) |
85 |
- install grub2 as if it were a new install; this was nigh trivial: |
86 |
"grub2-mkconfig -o /boot/grub/grub.cfg" followed by "grub-install /dev/sdf" |
87 |
- edit /etc/fstab to match the layout of the SSD (i.e., remove obsolete mount |
88 |
points and update the "/" line) |
89 |
- reboot (reconfiguring the boot order in the BIOS as necessary) |
90 |
- ??? |
91 |
- profit! ;-) |
92 |
|
93 |
(I hope that I didn't forget anything...) |
94 |
|
95 |
That is, it would have been this straightforward if I hadn't gotten the chroot |
96 |
wrong the first time around. I had to reboot into the main system, look up the |
97 |
correct chroot instructions, run "grub2-install /dev/sdf", and then reboot, |
98 |
which went successfully this time. Oh, and I had also forgotten to set the boot |
99 |
flag in the first step. Even so, it was pretty straightforward and required |
100 |
little research beforehand. |
101 |
|
102 |
Note that I don't know if you even need to chroot, I just did it because... I |
103 |
remembered needing to do that? To use the version of GRUB 2 that I emerged? I |
104 |
dunno, I suspected that GRUB's auto-detection features might detect stuff from |
105 |
the live CD that would be invalid when booting from the SSD. |
106 |
|
107 |
[ Why did I have to reboot to the main system? Because my dorm network sucks. |
108 |
After the Studentenwerk took over the network after the student networking |
109 |
team failed to find successors, we went from simple DHCP and a proper network |
110 |
to static addresses and PPPoE, if you can believe that; oh, and the network |
111 |
performs worse now, too. Anyway, I didn't want to bother with configuring |
112 |
the network from the live CD (which uses NetworkManager), so couldn't look up |
113 |
the instructions from there. |
114 |
|
115 |
*grumble* stupid over-complicated dorm network *grumble* ] |
116 |
|
117 |
Anyway, the only steps left are moving /usr/portage and swap to the SSD |
118 |
(the former is in progress right now). |
119 |
|
120 |
> > Is btrfs a good choice for / after all? |
121 |
> |
122 |
> I have decided: not without a full system backup (which I don't really want). |
123 |
|
124 |
After remembering just how small / really is (about 20 GB, even with /usr), I |
125 |
realised that there really is no reason *not* to include it in my automatic |
126 |
backups. I'm still not converting the SSD to btrfs, though. |
127 |
|
128 |
[...] |
129 |
-- |
130 |
Marc Joliet |
131 |
-- |
132 |
"People who think they know everything really annoy those of us who know we |
133 |
don't" - Bjarne Stroustrup |