From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E532F1381FA for ; Wed, 7 May 2014 15:12:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 82EBDE09EE; Wed, 7 May 2014 15:12:52 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 474B4E09AE for ; Wed, 7 May 2014 15:12:51 +0000 (UTC) Received: from marcec ([77.22.138.176]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0MQzIE-1WFxiZ259y-00UKwc for ; Wed, 07 May 2014 17:12:49 +0200 Date: Wed, 7 May 2014 17:12:39 +0200 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] planned btrfs conversion: questions Message-ID: <20140507171239.59adc7e3@marcec> In-Reply-To: <20140507005307.138665ad@marcec> References: <20140506121832.678ae781@marcec> <20140507005307.138665ad@marcec> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/kZOswS1MkJ6zXJgo39A/7lc"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:rZ3f85yTnjca10vAdD73PouQhQaSpz/yI14/q82y3nQSA40D5hO XXH71qeVdZD9sEcMG16JNEgaRB9XHck0icMol16iPYpEsFQE8vgmSddsPUZcgZWk2oXLSpA 2MJT1oNizEWf6dI4DQrBFc2Kx+zj6aZjX+N9BCTDMagMSlOt/ngHzytWjJWqTi+nOUWcK8Q nZSJx6Q1k8TNp2/gsNvsw== X-Archives-Salt: a9de443b-dc5d-4029-b435-6c513a8500e1 X-Archives-Hash: f11978357934bf41049e0214e5289c4e --Sig_/kZOswS1MkJ6zXJgo39A/7lc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 7 May 2014 00:53:07 +0200 schrieb Marc Joliet : [...] > > This migration will occur in conjunction with a migration of / + /usr t= o a > > cheap SSD that I just bought (Crucial M500 120 GB). The overall plan is= thus as > > follows: > >=20 > > Replace > >=20 > > /boot on /dev/md1 (EXT3, RAID 1) > > / (with assorted sub-directories, sans /usr) on /dev/md2 (EXT4, RAID 1= 0) > > the rest on LVM on /dev/md3 (all LVs EXT4, RAID 10) > >=20 > > with > >=20 > > / + /boot + /usr + swapfile on the SSD (EXT4) > > the rest (/home, my media partitions) on a btrfs RAID 10 >=20 > This part I think I will stick with. From what I've read so far, I would= n't > trust my entire system to btrfs. Since "the rest" consists of stuff I ei= ther > automatically backup (using rsnapshot) or have multiple copies of, I shou= ld be > able to recover from a broken btrfs file system fairly easily. >=20 > While I am unsure of my choice of RAID level (some comments on LWN.net cl= aim > that the MD RAID 10 is more comparable to btrfs' RAID 1, which I will att= empt to > verify myself beforehand). However, due to btrfs' live rebalancing featur= e, 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. >=20 > [...] > > The reason why I would choose EXT4 for the SSD is that btrfs still lack= s 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: > >=20 > > "SSD (Flash storage) awareness (TRIM/Discard for reporting free block= s for > > reuse) and optimizations (e.g. avoiding unnecessary seek optimization= s, > > sending writes in clusters, even if they are from unrelated files. Th= is > > results in larger write operations and faster write throughput)" > >=20 > > Does EXT4 also implement such optimisations for SSDs? >=20 > I will also go ahead with this (despite the open questions), although I w= ill > leave swap on the LVM for now. I think tonight (well, today) I "just" wan= t to > get the SSD running. Furthermore, "btrfs convert" should be able to up-co= nvert > it in the future once btrfs is "production ready" (both articles make a > guesstimate of about 1-2 years). >=20 > I think I would also prefer running a few days from the SSD before conver= ting > "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. Aft= er that, though, it feels like there are few noticeable advantages in everyd= ay 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 mentio= ning. - 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 le= gacy GRUB's configuration files on my desktop always felt like a chore.) The whole procedure wasn't that hard, either (ordered slightly more logical= ly 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/sd= f" - edit /etc/fstab to match the layout of the SSD (i.e., remove obsolete mou= nt 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 chr= oot 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 f= rom 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 suck= s. After the Studentenwerk took over the network after the student networking team failed to find successors, we went from simple DHCP and a proper net= work to static addresses and PPPoE, if you can believe that; oh, and the netwo= rk 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 loo= k 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? >=20 > I have decided: not without a full system backup (which I don't really wa= nt). 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. [...] --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/kZOswS1MkJ6zXJgo39A/7lc Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTak1uAAoJEL/Q5oYsiHj0w78QAJAx8rM0fLUCMOoK+ETKBp/a RbQc6M5JVzf516PtD5sqehdo+dt5ttLiUoOOMPI4MRZjQgCWkBNHFGE79PLfvpKO pz8hms25olAFu6vBvEFvBjCTQTUXwW5IuP5uwrKtVCEtJmFpQrLN0HsHRmgv83Py N3m0SgepuxSFD/6YdFgBR4mDWuFKhf57W/Yg68hAR050MHQJt/iVcC3ZNL1YpocF qmD2z++D9IUCPCRp+8D/HKo2KASHA6YOP20TUW/Uu9l5Z9mEGU0y6vtWxGZRRWHC 3sNrxCcC6qDkniI75ddYM0kjEiEkuZ/ozJxTmCbwhmkuqgOTrCSmo/COB3mZT8hq f1BiwQYssrYPaufOUP5iJUe6nnjILT6Ve1Z/BqpOa5TTkeQyHWJMB7C7waFKa+js POJMcf6zzAJDL1blB7Sku+4m55Dc79bS9tDSS+4KALEPrYHxq+K8atCKtxqSUm3W WTznnWyIT5B+VK9RsMPMyXqGZt62VOrp50tjPXWDCKHxZlSIjGvYu4Y0eRp5FHuw skDP0uC+Wt3PjdcxZh6cVbyBn8aj79lLzR8THauFsHiM8nBxwELFjn1oA7wmLJAo ufCUG0unVZMqlcdB2N0ySdz+CfIRWGxAsCkMrZ3H+3G1gP6VBjKwebgKw/jXvPme 3QT9KYzaDPRSRnGNT9my =2vn7 -----END PGP SIGNATURE----- --Sig_/kZOswS1MkJ6zXJgo39A/7lc--