From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id ADBFB1381FA for ; Fri, 9 May 2014 21:05:30 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A5C30E09B8; Fri, 9 May 2014 21:05:25 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 89198E0980 for ; Fri, 9 May 2014 21:05:24 +0000 (UTC) Received: from marcec ([77.22.138.176]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0M6eTo-1X3rL50K28-00wYI3 for ; Fri, 09 May 2014 23:05:23 +0200 Date: Fri, 9 May 2014 23:05:15 +0200 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] planned btrfs conversion: questions Message-ID: <20140509230515.6c97644d@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_/nEOW02wujs32JbeRrI/Z8jC"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:FsGSNFtUBmAOnGUx+2evTU5bxIksqsAQ7ZT+VfDu0+g0iJzlZU6 mIh+dYYGdseuPVZdvGwVyzhOyNa75gNst32/8Va3E4bPGeahVdOSdUloynQ/qD3LoxRLOBE FC+uv+tLcc5r12gxFTM8Sgqx9NmYgrE9hDXk18j1ENPhRWq7Nwmk/FCvn4GXEU/UDf7UnrW fkEDo0Eh/3oqPukkoeZ0w== X-Archives-Salt: 1d9bdfb4-ef7e-4af7-9c5c-707bc1adc16e X-Archives-Hash: 7e594ad715e91ebe7571da1b3a40a0c4 --Sig_/nEOW02wujs32JbeRrI/Z8jC Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable OK, I am in the middle of copying over my data from my backups to the fresh= ly created btrfs file system :-) . Read more below. Am Wed, 7 May 2014 00:53:07 +0200 schrieb Marc Joliet : [...] > 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. I went with RAID 10 for data and RAID 1 for meta-data. I will see how the d= isk usage actually turns out and can decide from there whether I want to change either one if I'm not satisfied. > [...] > > 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. So, as before, the conversion was straightforward, since the RAID + LVM only contained /home and data, thus I could convert without rebooting (though I = will reboot once the backups are restored, just to see if that works as expected= ). Anyway, I performed the following steps: - remount all affected partitions read-only - perform one last backup - unmount the affected partitions - shut down the logical volumes and the RAID (also, remove mdadm, mdraid and lvm from all run-levels) - run "mkfs.btrfs -f -m raid1 -d raid10 -L MARCEC_STORAGE /dev/sd{a,b,c,d}"= (-f because the HDDs still had a partition table) - create subvolumes where I used to have separate partitions (adjusting permissions where necessary) - rsync /home from the backup drive (which was surprisingly fast) What I am now in the middle of (2/3 of the way through) is syncing my media partitions. After that, the conversion will be complete, and I will hope and pray to our noodly overlord that I don't encounter any bugs. [...] > Thus the question arises: are there any show-stopper bugs in gentoo-sourc= es > 3.14.x that I should be aware about? They don't have to be directly btrfs > related. This is still an open question. I of course already upgraded prior to the b= trfs conversion and haven't noticed anything out of the ordinary, but I would be interested in anybody else's experience. One other thing I noticed: my old RAID had the distinct disadvantage that t= he newest drive I had added to it had a different alignment than the old ones. Since I had to copy the partition table from one of the existing drives, it= was not possible to accommodate this (though I only found out after recently running "blockdev --getalignoff"). I suspect btrfs could be able to deal wi= th that better than mdraid, and searching for "alignment" on the btrfs wiki sh= ows results which heavily imply that it in fact can (quote from the description= of the btrfs_chunk data structure: "Optimal alignment parameters for block I/O= "). Anyway, everything seems to be running fine so far :-) . [...] --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/nEOW02wujs32JbeRrI/Z8jC Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTbUMQAAoJEL/Q5oYsiHj0w80P/2wUF1yJCyCV0o2aXUxJL7wj OiNJXjBrzfb70peWVs+R8as8gYTcWBwkEsndJ/PCbh8hhnjnQP2hGxDmIo32KPco h7RB0aGFpgQazOPYwh0o7h3vNRjFSi/NcuAtWuoXJKhYQvL1OfRB66q3uovZxmLv NczKte2B8h0F8FqQ3mdf3zfotpJjcm1J9/PHxb+0QeKpXeQr3a02LW0vVDYZRIw0 dRbgF7hsHez4SA76AGKz9GZoEJ9MRgG4qyu3cGefbR3drjFoD9OHWwLxoLiB7QLQ /9sZHd4uHjYrEmU/gegSGe15livbDO8fbYuGMH9GrioMgg6AcdbD7Iyp0AuasUqb ExUBzHQgT7hJhpHKB++Zgt2Xk3DNBHJnRiinwPOIOOmye+KPhwWQYaNoIHnwV/20 fpP8s7Q4F/YSXhK0ywuJ/ES6YoM/yhicicG8tl8fZDhlBNq3n9fdu+uV/ry0NPuG lLvzujN5gBt82kDmK9btdwMOUf9A/5o7vtBj3TmYzwYDykr5uPUY8zqFaAPaELaW yWeJTUk9so1n32TzWkT2fwySArnMohwisf2y5WRFIO5GmirSHmzCg4eE5zhxkm4w gU4Rz4IwaG0IG8D2umN1h4fiA/faOAJy2KvwF85E6e4RIfQkcrQHCRhPXitquX1e moUYW4SaXUrMYHJ8KEth =q4W2 -----END PGP SIGNATURE----- --Sig_/nEOW02wujs32JbeRrI/Z8jC--