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 C57801381FA for ; Wed, 7 May 2014 02:33:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 43628E09F0; Wed, 7 May 2014 02:33:53 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 1A0E0E09BA for ; Wed, 7 May 2014 02:33:52 +0000 (UTC) Received: from [192.168.1.97] (pool-173-71-214-138.clppva.fios.verizon.net [173.71.214.138]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jcallen) by smtp.gentoo.org (Postfix) with ESMTPSA id D40F333FBD4 for ; Wed, 7 May 2014 02:33:50 +0000 (UTC) Message-ID: <53699B8A.5040802@gentoo.org> Date: Tue, 06 May 2014 22:33:46 -0400 From: Jonathan Callen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 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 To: gentoo-user@lists.gentoo.org Subject: [gentoo-user] Re: planned btrfs conversion: questions References: <20140506121832.678ae781@marcec> In-Reply-To: <20140506121832.678ae781@marcec> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Archives-Salt: 6ee1e5ca-5ca3-480d-8ca8-55f921d34aa4 X-Archives-Hash: 913863c80dad2c0a14ca06da8ab78db5 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/06/2014 06:18 AM, Marc Joliet wrote: > Hi all, > > I've become increasingly motivated to convert to btrfs. From what I've seen, it has become > increasingly stable; enough so that it is apparently supposed to become the default FS on > OpenSuse in 13.2. > > I am motivated by various reasons: > > - The experience of insignificant data loss after a reboot after no (visible) problems during > normal operations (no similar occurrence since). I suspect this would have been discovered > sooner by btrfs' data checksumming. > > While the data lost was of a small amount, not to mention insignificant (internet pictures) and > could be retrieved again easily, I worry that this sort of silent corruption might happen to > data that I *do* care about. My backups would become less than useless if I were to discover > such corruption too late. > > - The outright sexy multiple device support :) . > > 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 > > (which replaces an older plan to recreate the RAID 10 + LVM to use the whole disks with the > current 1.2 metadata format) > > The goals are, in addition to alleviating my data safety concerns above, to guarantee that I > don't need an initramfs at boot (hence the SSD), and to greatly simplify my partitioning scheme > (I just have too many separate logical volumes ;-) ). Any added performance is "just" a nice > bonus. > > 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? > > So I guess I want to know: does anybody have any further suggestions to make? Is btrfs a good > choice for / after all? And should I be using the most recent kernel versions? (I would go with > no, despite the advice from upstream, because the changes in the last two versions don't seem > to be particularly user visible, at least to me, from reading kernelnewbies.org.) > > I also have a more specific question regarding RAID 10: the btrfs wiki says 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 thought maybe somebody here knows more details and/or gotchas. From my > understanding, 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 broken, must check) spare and wish to > be able to upgrade without having to buy four HDDs at once. > > Now to the migration plan: first, partition the SSD and copy all relevant file systems to it; > this will be done from a Live-CD (SystemRescueCD). After I have configured the mount options > appropriately and can boot from that, I should be able to mount the other file systems (/home > and my media partitions) read-only from the actual system and do the RAID + LVM -> btrfs > migration from there. > > Note that I will in general follow the advice from [1-3], and if people recommend btrfs on /, > then I will also try to get relevant information from [4]. > > [0] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#RAID_and_data_replication [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 > > Greetings and thanks in advance for any help given > As I understand it, when you use BTRFS's internal "RAID1" implementation, the filesystem ensures that all the data is on at least two different drives, but otherwise doesn't require that the drives are the same size, etc. The amount of available space will effectively be the lesser of 50% of the total space on all drives or 100% of the total of all the drives *except* the largest (in which case, it would be likely that *all* of your data would be stored on the largest drive in addition to being split among the other drives). - -- Jonathan Callen -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJTaZt/AAoJELHSF2kinlg4geoP/Rz1Kn4Bu0c/hXr5kuPkP/wo BXrfmKQySrWRaeXUx2Am1K7S0ZplM3gLm75NIM6dceeeucSj71x4AVFUY6Ds8B4q 7WGmALfdSfzFNcwLhiLdI1WCkCGGQr3deWCRg9AUFt742D3Uo9n6k2XQecbxsw56 CFwcazECZkDOMkbXr+gL+E0uj2RUM09gquhuZkoXZGIp6bbS7bDCgcX6KKv8wz/s etIbgd/mcvqBBQrm6LzjYthYlNB8osH9Szvq7boCMOkzLF5l3JDtmLdN6c30H04H DUXSOqt5ZAzH7uXAj5sgT01/1DpqOg0WRDLvVw+y+bagwIsN1stns6rWAIZI64Pf Do1J8pX5iAcPsMr+YjmiclgwJxRQlC77HHhn48qFqjrMaUhdqk4XGYoWFhvpvGs1 u4yhZMOt0JpBH5sj8IlJEcjTMu8RS6Zsido6CxlwOOAGikrqRJq9XTgDvVUVFnUQ AyAeIbI5CHjbe0nbvbUJvz+gsHTdzeY2F+Q7APK4LTzSDMzVIDgC5f4WcJSCnVz5 u4IwEPd6R/m2jII4x3gU+0A5LKaP4CyPFsTjeZjOu6rgIyITN6Cmnb248u3Z0jVh nYX2amJNn4/53jQfiLC2PW35O3QsDn1VrSL23b74xHJIvsTENCtjwBTI+yav3val Yr64ISgBtRdbSeh5WWD4 =E3vP -----END PGP SIGNATURE-----