Gentoo Archives: gentoo-user

From: Jonathan Callen <jcallen@g.o>
To: gentoo-user@l.g.o
Subject: [gentoo-user] Re: planned btrfs conversion: questions
Date: Wed, 07 May 2014 02:33:59
Message-Id: 53699B8A.5040802@gentoo.org
In Reply to: [gentoo-user] planned btrfs conversion: questions by Marc Joliet
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA512
3
4 On 05/06/2014 06:18 AM, Marc Joliet wrote:
5 > Hi all,
6 >
7 > I've become increasingly motivated to convert to btrfs. From what I've seen, it has become
8 > increasingly stable; enough so that it is apparently supposed to become the default FS on
9 > OpenSuse in 13.2.
10 >
11 > I am motivated by various reasons:
12 >
13 > - The experience of insignificant data loss after a reboot after no (visible) problems during
14 > normal operations (no similar occurrence since). I suspect this would have been discovered
15 > sooner by btrfs' data checksumming.
16 >
17 > While the data lost was of a small amount, not to mention insignificant (internet pictures) and
18 > could be retrieved again easily, I worry that this sort of silent corruption might happen to
19 > data that I *do* care about. My backups would become less than useless if I were to discover
20 > such corruption too late.
21 >
22 > - The outright sexy multiple device support :) .
23 >
24 > This migration will occur in conjunction with a migration of / + /usr to a cheap SSD that I
25 > just bought (Crucial M500 120 GB). The overall plan is thus as follows:
26 >
27 > Replace
28 >
29 > /boot on /dev/md1 (EXT3, RAID 1) / (with assorted sub-directories, sans /usr) on /dev/md2
30 > (EXT4, RAID 10) the rest on LVM on /dev/md3 (all LVs EXT4, RAID 10)
31 >
32 > with
33 >
34 > / + /boot + /usr + swapfile on the SSD (EXT4) the rest (/home, my media partitions) on a btrfs
35 > RAID 10
36 >
37 > (which replaces an older plan to recreate the RAID 10 + LVM to use the whole disks with the
38 > current 1.2 metadata format)
39 >
40 > The goals are, in addition to alleviating my data safety concerns above, to guarantee that I
41 > don't need an initramfs at boot (hence the SSD), and to greatly simplify my partitioning scheme
42 > (I just have too many separate logical volumes ;-) ). Any added performance is "just" a nice
43 > bonus.
44 >
45 > The reason why I would choose EXT4 for the SSD is that btrfs still lacks support for swap files
46 > and I worry about creating a swap partition on the SSD. Is that warranted, or will the
47 > wear-levelling of the SSD handle that just fine? Do swap partitions support SSDs specially?
48 > Also, does anyone know whether EXT4 goes beyond "merely" supporting TRIM? That is, the btrfs
49 > wiki advertises the following:
50 >
51 > "SSD (Flash storage) awareness (TRIM/Discard for reporting free blocks for reuse) and
52 > optimizations (e.g. avoiding unnecessary seek optimizations, sending writes in clusters, even
53 > if they are from unrelated files. This results in larger write operations and faster write
54 > throughput)"
55 >
56 > Does EXT4 also implement such optimisations for SSDs?
57 >
58 > So I guess I want to know: does anybody have any further suggestions to make? Is btrfs a good
59 > choice for / after all? And should I be using the most recent kernel versions? (I would go with
60 > no, despite the advice from upstream, because the changes in the last two versions don't seem
61 > to be particularly user visible, at least to me, from reading kernelnewbies.org.)
62 >
63 > I also have a more specific question regarding RAID 10: the btrfs wiki says that you can add
64 > devices with different sizes to a multiple device setup, but I don't think it says to which
65 > RAID levels this applies and how. From [0] I would say it works with RAID 10 (since that's what
66 > the example uses), but thought maybe somebody here knows more details and/or gotchas. From my
67 > understanding, this means that I can iteratively upgrade my RAID 10 to larger drives and have
68 > btrfs use all of the available space (or at least as much as is possible). This is important to
69 > me because I currently have 4 320 GB HDDs + 1 (possibly broken, must check) spare and wish to
70 > be able to upgrade without having to buy four HDDs at once.
71 >
72 > Now to the migration plan: first, partition the SSD and copy all relevant file systems to it;
73 > this will be done from a Live-CD (SystemRescueCD). After I have configured the mount options
74 > appropriately and can boot from that, I should be able to mount the other file systems (/home
75 > and my media partitions) read-only from the actual system and do the RAID + LVM -> btrfs
76 > migration from there.
77 >
78 > Note that I will in general follow the advice from [1-3], and if people recommend btrfs on /,
79 > then I will also try to get relevant information from [4].
80 >
81 > [0] https://btrfs.wiki.kernel.org/index.php/SysadminGuide#RAID_and_data_replication [1]
82 > https://wiki.archlinux.org/index.php/Solid_State_Drives [2]
83 > https://wiki.archlinux.org/index.php/Btrfs [3] http://wiki.gentoo.org/wiki/Btrfs [4]
84 > http://wiki.gentoo.org/wiki/Btrfs_system_root
85 >
86 > Greetings and thanks in advance for any help given
87 >
88
89 As I understand it, when you use BTRFS's internal "RAID1" implementation, the filesystem ensures
90 that all the data is on at least two different drives, but otherwise doesn't require that the
91 drives are the same size, etc. The amount of available space will effectively be the lesser of
92 50% of the total space on all drives or 100% of the total of all the drives *except* the largest
93 (in which case, it would be likely that *all* of your data would be stored on the largest drive in
94 addition to being split among the other drives).
95
96 - --
97 Jonathan Callen
98 -----BEGIN PGP SIGNATURE-----
99 Version: GnuPG v2.0.22 (GNU/Linux)
100 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
101
102 iQIcBAEBCgAGBQJTaZt/AAoJELHSF2kinlg4geoP/Rz1Kn4Bu0c/hXr5kuPkP/wo
103 BXrfmKQySrWRaeXUx2Am1K7S0ZplM3gLm75NIM6dceeeucSj71x4AVFUY6Ds8B4q
104 7WGmALfdSfzFNcwLhiLdI1WCkCGGQr3deWCRg9AUFt742D3Uo9n6k2XQecbxsw56
105 CFwcazECZkDOMkbXr+gL+E0uj2RUM09gquhuZkoXZGIp6bbS7bDCgcX6KKv8wz/s
106 etIbgd/mcvqBBQrm6LzjYthYlNB8osH9Szvq7boCMOkzLF5l3JDtmLdN6c30H04H
107 DUXSOqt5ZAzH7uXAj5sgT01/1DpqOg0WRDLvVw+y+bagwIsN1stns6rWAIZI64Pf
108 Do1J8pX5iAcPsMr+YjmiclgwJxRQlC77HHhn48qFqjrMaUhdqk4XGYoWFhvpvGs1
109 u4yhZMOt0JpBH5sj8IlJEcjTMu8RS6Zsido6CxlwOOAGikrqRJq9XTgDvVUVFnUQ
110 AyAeIbI5CHjbe0nbvbUJvz+gsHTdzeY2F+Q7APK4LTzSDMzVIDgC5f4WcJSCnVz5
111 u4IwEPd6R/m2jII4x3gU+0A5LKaP4CyPFsTjeZjOu6rgIyITN6Cmnb248u3Z0jVh
112 nYX2amJNn4/53jQfiLC2PW35O3QsDn1VrSL23b74xHJIvsTENCtjwBTI+yav3val
113 Yr64ISgBtRdbSeh5WWD4
114 =E3vP
115 -----END PGP SIGNATURE-----