Am Wed, 7 May 2014 00:53:07 +0200 schrieb Marc Joliet <mar...@gmx.de>:
[...] > > This migration will occur in conjunction with a migration of / + /usr to a > > cheap SSD that I just bought (Crucial M500 120 GB). The overall plan is > > thus as > > follows: > > > > Replace > > > > /boot on /dev/md1 (EXT3, RAID 1) > > / (with assorted sub-directories, sans /usr) on /dev/md2 (EXT4, RAID 10) > > the rest on LVM on /dev/md3 (all LVs EXT4, RAID 10) > > > > with > > > > / + /boot + /usr + swapfile on the SSD (EXT4) > > the rest (/home, my media partitions) on a btrfs RAID 10 > > This part I think I will stick with. From what I've read so far, I wouldn't > trust my entire system to btrfs. Since "the rest" consists of stuff I either > automatically backup (using rsnapshot) or have multiple copies of, I should be > able to recover from a broken btrfs file system fairly easily. > > While I am unsure of my choice of RAID level (some comments on LWN.net claim > that the MD RAID 10 is more comparable to btrfs' RAID 1, which I will attempt > to > verify myself beforehand). However, due to btrfs' live rebalancing feature, I > worry less about this. By the time I really need more space the RAID 5/6 code > (and maybe N-way mirroring) ought to be stable (or at least finished), or I > can switch to RAID 1 if I need the flexibility. > > [...] > > The reason why I would choose EXT4 for the SSD is that btrfs still lacks > > support > > for swap files and I worry about creating a swap partition on the SSD. Is > > that > > warranted, or will the wear-levelling of the SSD handle that just fine? Do > > swap > > partitions support SSDs specially? Also, does anyone know whether EXT4 goes > > beyond "merely" supporting TRIM? That is, the btrfs wiki advertises the > > following: > > > > "SSD (Flash storage) awareness (TRIM/Discard for reporting free blocks for > > reuse) and optimizations (e.g. avoiding unnecessary seek optimizations, > > sending writes in clusters, even if they are from unrelated files. This > > results in larger write operations and faster write throughput)" > > > > Does EXT4 also implement such optimisations for SSDs? > > I will also go ahead with this (despite the open questions), although I will > leave swap on the LVM for now. I think tonight (well, today) I "just" want to > get the SSD running. Furthermore, "btrfs convert" should be able to up-convert > it in the future once btrfs is "production ready" (both articles make a > guesstimate of about 1-2 years). > > I think I would also prefer running a few days from the SSD before converting > "the rest" to btrfs, which should be fairly simple at that point. Weeee, this part is done as of this morning! I am now successfully booting from the SSD with GRUB 2. So far I've noticed the following advantages: - RAID shutdown actually succeeds now (it never did before with / on a RAID 10). - It feels like my boot time was halved (not counting the BIOS and boot loader, though); logging into my desktop also feels much quicker now. After that, though, it feels like there are few noticeable advantages in everyday usage (I expect portage to become faster, though). Obviously these types of speed-ups are to be expected from an SSD, but it still feels worth mentioning. - GRUB 2 is so much nicer to use than legacy GRUB! Now every time I install a new kernel, I just run "grub2-mkconfig -o /boot/grub/grub.cfg" and reboot, and everything will just work! (I was already used to this on my work/uni laptop, so manually editing legacy GRUB's configuration files on my desktop always felt like a chore.) The whole procedure wasn't that hard, either (ordered slightly more logically than what I actually did): - "emerge grub:2" (I have it in parallel to legacy GRUB for now) - use gparted to create one large EXT4 boot partition on the SSD - boot to a systemrescuecd - "cp -a" the / + /usr + ... to the SSD (yes, I should have used rsync) - copy the kernel images to /boot on the SSD - chroot into the SSD (following the Gentoo handbook) - install grub2 as if it were a new install; this was nigh trivial: "grub2-mkconfig -o /boot/grub/grub.cfg" followed by "grub-install /dev/sdf" - edit /etc/fstab to match the layout of the SSD (i.e., remove obsolete mount points and update the "/" line) - reboot (reconfiguring the boot order in the BIOS as necessary) - ??? - profit! ;-) (I hope that I didn't forget anything...) That is, it would have been this straightforward if I hadn't gotten the chroot wrong the first time around. I had to reboot into the main system, look up the correct chroot instructions, run "grub2-install /dev/sdf", and then reboot, which went successfully this time. Oh, and I had also forgotten to set the boot flag in the first step. Even so, it was pretty straightforward and required little research beforehand. Note that I don't know if you even need to chroot, I just did it because... I remembered needing to do that? To use the version of GRUB 2 that I emerged? I dunno, I suspected that GRUB's auto-detection features might detect stuff from the live CD that would be invalid when booting from the SSD. [ Why did I have to reboot to the main system? Because my dorm network sucks. After the Studentenwerk took over the network after the student networking team failed to find successors, we went from simple DHCP and a proper network to static addresses and PPPoE, if you can believe that; oh, and the network performs worse now, too. Anyway, I didn't want to bother with configuring the network from the live CD (which uses NetworkManager), so couldn't look up the instructions from there. *grumble* stupid over-complicated dorm network *grumble* ] Anyway, the only steps left are moving /usr/portage and swap to the SSD (the former is in progress right now). > > Is btrfs a good choice for / after all? > > I have decided: not without a full system backup (which I don't really want). After remembering just how small / really is (about 20 GB, even with /usr), I realised that there really is no reason *not* to include it in my automatic backups. I'm still not converting the SSD to btrfs, though. [...] -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: PGP signature
