Am 27.10.2014 um 17:52 schrieb Pandu Poluan: > > > On Oct 27, 2014 10:40 PM, "Rich Freeman" <ri...@gentoo.org > <mailto:ri...@gentoo.org>> wrote: > > > > On Mon, Oct 27, 2014 at 11:22 AM, Mick <michaelkintz...@gmail.com > <mailto:michaelkintz...@gmail.com>> wrote: > > > > > > Thanks Rich, I have been reading your posts about btrfs with > interest, but > > > have not yet used it on my systems. Is btrfs agreeable with SSDs, > or should I > > > be using f2fs: > > > > > > > Btrfs will auto-detect SSDs and optimize itself differently, and is > > generally considered to be fine on SSDs. Of course, btrfs itself is > > experimental and may eat your data, especially if you get it too full, > > but you'll be no worse off for running it on an SSD. > > > > I doubt you'll find any general-purpose filesystem that works as well > > overall on an SSD as something like f2fs as this is log-based and > > designed with SSDs in mind. However, f2fs is also very immature and > > also carries risks, and the last time I checked it was missing some > > features like xattrs as well. It also doesn't have anything like > > btrfs send to serialize your data. > > > > zfs on linux might be another option. I don't know how well it > > handles SSDs in general, and you have to fuss with FUSE and a boot > > partition as I don't think grub supports it - it could be a bit of a > > PITA for a single-drive system. However, it is probably more mature > > than btrfs overall, and it certainly supports send. > > > > I just had a btrfs near-miss which caused me to rethink how I'm > > managing my own storage. I was half-tempted to blog on it - it is a > > bit frustrating as I believe we're right in the middle of the shift > > between the traditional filesystems and the next-generation ones. > > Sticking with the old means giving up a lot of potential benefits, but > > there are a lot of issues with jumping ship as well as the new systems > > all lack maturity or are not feature-complete yet. I was looking at > > f2fs, btrfs, and zfs again this weekend and the issues I struggle with > > are the immaturity of btrfs and f2fs, the lack of working parity raid > > on btrfs, the lack of many features on f2fs, and the inability to > > resize vdevs on zfs which means on a system with few drives you get > > locked in. I suspect all of those will change in time, but not yet! > > > > -- > > Rich > > > > ZoL (ZFS on Linux) nowadays is implemented using DKMS instead of FUSE, > thus running in kernelspace, and (relatively) easier to put into an > initramfs. > > Updating is a beeyotch on binary-based distros as it requires a > recompile. Not a big deal for us Gentooers :-) > > vdevs can grow, but they can't (yet) shrink. And putting ZFS on > SSDs... not recommended. Rather, ZFS can employ SSDs to act as a > 'write cache' for the spinning HDDs. > > In my personal opinion, the 'killer' feature of ZFS is that it's built > from the ground up to provide maximum data integrity. The second > feature is its high performance COW snapshot ability. You can do an > obscene amount of snapshots if you want (but don't actually do it; > managing more than a hundred snapshots is a Royal PITA). And it's also > able to serialize the snapshots, allowing perfect delta replication > to another system. This saves a lot of time doing bit-perfect backup > because only changed blocks will be transferred. And you can ship a > snapshot instead of the whole filesystem, allowing online backup. > > (And yes, actually deployed ZoL on my previous employer's email > system, with the aforementioned snapshot-shipping backup strategy). > > Other features include: Much easier mounting (no need to mess with > fstab), built-in NFS support for higher throughput, and ability to > easily rebuild a pool merely by installing the drives (in any order) > into a new box and let ZFS scan for all the metadata. > > The most serious drawback in my opinion is ZoL's nearly insatiable > appetite for RAM. Unless you purposefully limit its RAM usage, ZoL's > cache will consume nearly all available memory, causing memory > fragmentation and ending with OOM. > > Rgds, > -- >
I haven't run into oom situations caused by zfs. Unlike oom's caused by konqueror, chromium or gcc...
