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 |
> |
46 |
|
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. |
49 |
|
50 |
Updating is a beeyotch on binary-based distros as it requires a recompile. |
51 |
Not a big deal for us Gentooers :-) |
52 |
|
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. |
56 |
|
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. |
66 |
|
67 |
(And yes, actually deployed ZoL on my previous employer's email system, |
68 |
with the aforementioned snapshot-shipping backup strategy). |
69 |
|
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. |
74 |
|
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. |
79 |
|
80 |
Rgds, |
81 |
-- |