Gentoo Archives: gentoo-user

From: Pandu Poluan <pandu@××××××.info>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Safeguarding strategies against SSD data loss
Date: Mon, 27 Oct 2014 16:52:46
In Reply to: Re: [gentoo-user] Safeguarding strategies against SSD data loss by Rich Freeman
1 On Oct 27, 2014 10:40 PM, "Rich Freeman" <rich0@g.o> wrote:
2 >
3 > On Mon, Oct 27, 2014 at 11:22 AM, Mick <michaelkintzios@×××××.com> wrote:
4 > >
5 > > Thanks Rich, I have been reading your posts about btrfs with interest,
6 but
7 > > have not yet used it on my systems. Is btrfs agreeable with SSDs, or
8 should I
9 > > be using f2fs:
10 > >
11 >
12 > Btrfs will auto-detect SSDs and optimize itself differently, and is
13 > generally considered to be fine on SSDs. Of course, btrfs itself is
14 > experimental and may eat your data, especially if you get it too full,
15 > but you'll be no worse off for running it on an SSD.
16 >
17 > I doubt you'll find any general-purpose filesystem that works as well
18 > overall on an SSD as something like f2fs as this is log-based and
19 > designed with SSDs in mind. However, f2fs is also very immature and
20 > also carries risks, and the last time I checked it was missing some
21 > features like xattrs as well. It also doesn't have anything like
22 > btrfs send to serialize your data.
23 >
24 > zfs on linux might be another option. I don't know how well it
25 > handles SSDs in general, and you have to fuss with FUSE and a boot
26 > partition as I don't think grub supports it - it could be a bit of a
27 > PITA for a single-drive system. However, it is probably more mature
28 > than btrfs overall, and it certainly supports send.
29 >
30 > I just had a btrfs near-miss which caused me to rethink how I'm
31 > managing my own storage. I was half-tempted to blog on it - it is a
32 > bit frustrating as I believe we're right in the middle of the shift
33 > between the traditional filesystems and the next-generation ones.
34 > Sticking with the old means giving up a lot of potential benefits, but
35 > there are a lot of issues with jumping ship as well as the new systems
36 > all lack maturity or are not feature-complete yet. I was looking at
37 > f2fs, btrfs, and zfs again this weekend and the issues I struggle with
38 > are the immaturity of btrfs and f2fs, the lack of working parity raid
39 > on btrfs, the lack of many features on f2fs, and the inability to
40 > resize vdevs on zfs which means on a system with few drives you get
41 > locked in. I suspect all of those will change in time, but not yet!
42 >
43 > --
44 > Rich
45 >
47 ZoL (ZFS on Linux) nowadays is implemented using DKMS instead of FUSE, thus
48 running in kernelspace, and (relatively) easier to put into an initramfs.
50 Updating is a beeyotch on binary-based distros as it requires a recompile.
51 Not a big deal for us Gentooers :-)
53 vdevs can grow, but they can't (yet) shrink. And putting ZFS on SSDs... not
54 recommended. Rather, ZFS can employ SSDs to act as a 'write cache' for the
55 spinning HDDs.
57 In my personal opinion, the 'killer' feature of ZFS is that it's built from
58 the ground up to provide maximum data integrity. The second feature is its
59 high performance COW snapshot ability. You can do an obscene amount of
60 snapshots if you want (but don't actually do it; managing more than a
61 hundred snapshots is a Royal PITA). And it's also able to serialize the
62 snapshots, allowing perfect delta replication to another system. This
63 saves a lot of time doing bit-perfect backup because only changed blocks
64 will be transferred. And you can ship a snapshot instead of the whole
65 filesystem, allowing online backup.
67 (And yes, actually deployed ZoL on my previous employer's email system,
68 with the aforementioned snapshot-shipping backup strategy).
70 Other features include: Much easier mounting (no need to mess with fstab),
71 built-in NFS support for higher throughput, and ability to easily rebuild a
72 pool merely by installing the drives (in any order) into a new box and let
73 ZFS scan for all the metadata.
75 The most serious drawback in my opinion is ZoL's nearly insatiable appetite
76 for RAM. Unless you purposefully limit its RAM usage, ZoL's cache will
77 consume nearly all available memory, causing memory fragmentation and
78 ending with OOM.
80 Rgds,
81 --


Subject Author
Re: [gentoo-user] Safeguarding strategies against SSD data loss Volker Armin Hemmann <volkerarmin@××××××××××.com>
Re: [gentoo-user] Safeguarding strategies against SSD data loss Rich Freeman <rich0@g.o>
Re: [gentoo-user] Safeguarding strategies against SSD data loss Tom H <tomh0665@×××××.com>