OK, I read several articles (the LWN.net series from December/January [5] and 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 <mar...@gmx.de>: [...] > 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 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 either 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 attempt 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 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. [...] > 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? 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-convert 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 converting "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, > 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 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., RAID5/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 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. From 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 just 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 larger 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 replace one drive with another, so I can keep my current setup; I just have to replace any failed drive manually (for now). Also (OT): the possibly broken drive (sda) might have simply been a loose SATA cable. The first time it spontaneously failed (triggering the minor data loss 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_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 [5] http://lwn.net/Articles/576276/ [6] http://arstechnica.com/information-technology/2014/01/bitrot-and-atomic-cows-inside-next-gen-filesystems/ [7] http://www.zdnet.com/btrfs-hands-on-my-first-experiments-with-a-new-linux-file-system-7000023681/ > Greetings and thanks in advance for any help given -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup
signature.asc
Description: PGP signature
