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----- |