Re: [gentoo-user] Safeguarding strategies against SSD data loss

[Volker Armin Hemmann <volkerarmin@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 4247 bytes --]

Am 27.10.2014 um 17:52 schrieb Pandu Poluan:
>
>
> On Oct 27, 2014 10:40 PM, "Rich Freeman" <rich0@gentoo.org
> <mailto:rich0@gentoo.org>> wrote:
> >
> > On Mon, Oct 27, 2014 at 11:22 AM, Mick <michaelkintzios@gmail.com
> <mailto:michaelkintzios@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...

[-- Attachment #2: Type: text/html, Size: 5862 bytes --]