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 168261381FA for ; Tue, 6 May 2014 22:53:23 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 433CEE0943; Tue, 6 May 2014 22:53:18 +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 EDEFFE0853 for ; Tue, 6 May 2014 22:53:16 +0000 (UTC) Received: from marcec ([77.22.138.176]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M1nOg-1WxpgH0wag-00tkHb for ; Wed, 07 May 2014 00:53:15 +0200 Date: Wed, 7 May 2014 00:53:07 +0200 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] planned btrfs conversion: questions Message-ID: <20140507005307.138665ad@marcec> In-Reply-To: <20140506121832.678ae781@marcec> References: <20140506121832.678ae781@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_/QhLTfkPfSyqTY92v4KecHu."; protocol="application/pgp-signature" X-Provags-ID: V03:K0:iv7WA+/51uEmcK/KH4kB1Kh5NNb8tUne/KlO9McmAdKaI1gJnHm Z9IBIugfZjB+r+8AGC7UILpX0lkib/fcRTcnzLs97mdhGOgYILv/0DTupMlIdCUYdzFas4s 5Ti1+e6s180+YoRRKmfdyNaWs8y0isuh8lh5b4/PLoGEV5P4QWw/bGW9tMSAz+lUB73JZ7C I8gpwdXRYzZg0teCjod9Q== X-Archives-Salt: 778fe772-bba3-4b9f-bf89-5f053e1c782b X-Archives-Hash: a22bb80d0d9d7ff5827ae89f6aea4b4b --Sig_/QhLTfkPfSyqTY92v4KecHu. Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable OK, I read several articles (the LWN.net series from December/January [5] a= nd a January article from ars technica [6]) and quite a lot of comments on btrfs today and can answer some of my questions myself. For completions sake, I also read a zdnet article series (starting at [7]),= but it wasn't quite as good as the other two IMHO. Am Tue, 6 May 2014 12:18:32 +0200 schrieb Marc Joliet : [...] > 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 t= hus as > follows: >=20 > Replace >=20 > /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) >=20 > with >=20 > / + /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 eith= er 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 attem= pt 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 co= de (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? D= o swap > partitions support SSDs specially? Also, does anyone know whether EXT4 go= es > beyond "merely" supporting TRIM? That is, the btrfs wiki advertises the > following: >=20 > "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)" >=20 > 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-conv= ert 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 converti= ng "the rest" to btrfs, which should be fairly simple at that point. [...] > Is btrfs a good choice for / after all? I have decided: not without a full system backup (which I don't really want= ). > And should I be using the most recent > kernel versions? (I would go with no, despite the advice from upstream, b= ecause > the changes in the last two versions don't seem to be particularly user > visible, at least to me, from reading kernelnewbies.org.) I changed my mind on this: I checked the change logs from the btrfs wiki and realised I should really give the notion of having the latest bug fixes more weight. *Especially* since the focus of the mainline btrfs development is stability and performance (and finalisation of central features, e.g., RAID= 5/6 support, but that's less important). Thus the question arises: are there any show-stopper bugs in gentoo-sources 3.14.x that I should be aware about? They don't have to be directly btrfs related. > I also have a more specific question regarding RAID 10: the btrfs wiki sa= ys > that you can add devices with different sizes to a multiple device setup,= but I > don't think it says to which RAID levels this applies and how. From [0] I= would > say it works with RAID 10 (since that's what the example uses), but thoug= ht > maybe somebody here knows more details and/or gotchas. From my understand= ing, > this means that I can iteratively upgrade my RAID 10 to larger drives and= have > btrfs use all of the available space (or at least as much as is possible)= . This > is important to me because I currently have 4 320 GB HDDs + 1 (possibly b= roken, > must check) spare and wish to be able to upgrade without having to buy fo= ur > HDDs at once. =46rom the [5] I learned that RAID 10 can be extended with *pairs* of drives,= so that answers that question. Since my SATA ports are all occupied, I can't j= ust hook up two new drives and remove the old ones. So I have a new question: does "btrfs replace" work if the new drive is lar= ger than the old one? Again, according to [0] it sounds like it should work, but it's not clear to me. As an addendum: btrfs does not support hot spares, but you can easily repla= ce one drive with another, so I can keep my current setup; I just have to repl= ace any failed drive manually (for now). Also (OT): the possibly broken drive (sda) might have simply been a loose S= ATA cable. The first time it spontaneously failed (triggering the minor data lo= ss mentioned above), adjusting the SATA cables got it to work again, albeit unstably. Today I adjusted the SATA cables again after a different drive (= sdd) spontaneously gave up yesterday, and sda started passing SMART tests (both = short and long) again (sdd passed, too). Color me confused :-/ . I should see if I can buy shorter SATA cables so they don't get in each others way so much. [...] > [0] > https://btrfs.wiki.kernel.org/index.php/SysadminGuide#RAID_and_data_repli= cation > [1] https://wiki.archlinux.org/index.php/Solid_State_Drives > [2] https://wiki.archlinux.org/index.php/Btrfs > [3] http://wiki.gentoo.org/wiki/Btrfs > [4] http://wiki.gentoo.org/wiki/Btrfs_system_root [5] http://lwn.net/Articles/576276/ [6] http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cow= s-inside-next-gen-filesystems/ [7] http://www.zdnet.com/btrfs-hands-on-my-first-experiments-with-a-new-linux-f= ile-system-7000023681/ > Greetings and thanks in advance for any help given --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/QhLTfkPfSyqTY92v4KecHu. Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTaWfYAAoJEL/Q5oYsiHj0JfMP/10HDJDtuohO9TBMXPBNQRrE uCG4hhD3eB8jk7jAuHr4qZG0VevDLcuF8R9a9jCHjTzqxprhHRbM2eCmrqrlUUNa UHBwSB8Euol1wPCKuUDp1LIClmsckwdR4guDcJNsMolQjugUQTleKRrXFUFglGxp 4l0DoGCR57PwTkBSzBAqP5I23yDv64J9PciVnar3J42eG9QpHhnwOMWBq1kHyzPO r/qZc4PEZDbiYGH8mojfFjc6qhhWsg0hyUW0xg0EN5TuPZjCjndw7gBY5yCi6kvV 8u25p7ON11/oXIJj9ynEpCLu3pgohqtqvlSRy8DRtJ9/6Bi63yJ0rLzm2UUIbzY6 e3C9b2FWMlOwnVKgclamrQU607en7pKQoHfXDOzXSirPo6h+c95GFvUebvbMvlCW dh708Hl7RamzSrg8xq5OMMJIHLTvwzVZfu6dUereIWIppl6LSSKKA5hI8tQR+GmP lXkNWsrBP6ZbFuGCkwTcEwiC+xiiay60zniwKsMUmTvchVvxaEMqiRIpCSckSI9l jIop2lwzdWGbzHHVEqL3KDWXjmBWFSN4iawFXAbf7/EN71tNPbBTu4gLtXYcd3VQ amoCBvhVPoMxU/jsOGs+XKrXCl/CLb/IPTSrpokrbj58NZMYSPZkGHgF8Up1qUzi MLAQq/jj7rRKDmG1I4Eh =qZXH -----END PGP SIGNATURE----- --Sig_/QhLTfkPfSyqTY92v4KecHu.--