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

[Rich Freeman <rich0@gentoo.org>]

On Mon, Oct 27, 2014 at 12:52 PM, Pandu Poluan <pandu@poluan.info> wrote:
>
> ZoL (ZFS on Linux) nowadays is implemented using DKMS instead of FUSE, thus
> running in kernelspace, and (relatively) easier to put into an initramfs.

Sorry about that.  I should have known that, but for some reason I got
that memory crossed in my brain...  :)

> vdevs can grow, but they can't (yet) shrink.

Can you point to any docs on that, including any limitations/etc?  The
inability to expand raid-z the way you can do so with mdadm was one of
the big things that has been keeping me away from zfs.  I understand
that it isn't so important when you're dealing with large numbers of
disks (backblaze's storage pods come to mind), but when you have only
a few disks being able to manipulate them one at a time is very
useful.  Growing is the more likely use case than shrinking.  Then
again, at some point if you want to replace smaller drives with larger
ones you might want a way to remove drives from a vdev.

The one thing that btrfs does that is helpful here is that it works
with data in "chunks" and not at the whole drive level.  That is,
block 1 on drive A is not hard-mapped to block 1 on drive B in the way
that it is with a traditional RAID.  That makes it easy to have a
non-redundant set of disks and then switch it to raid1 mode while
leaving the existing data unmirrored - new chunks get mirrored, and
old ones don't, and you can run a command telling the system to copy
all the old data into new mirrored chunks.

> And putting ZFS on SSDs... not recommended. Rather, ZFS can employ
> SSDs to act as a 'write cache' for the spinning HDDs.

It can operate as a read-cache as well, right?  I believe you'd need
separate drives/partitions for that.

>
> In my personal opinion, the 'killer' feature of ZFS is that it's built from
> the ground up to provide maximum data integrity.

That and the snapshots are actually common to both btrfs and ZFS.  The
main advantages of ZFS over btrfs is that the codebase is much more
stable (though ZoL is a newer port of it), and that it has more
enterprise-oriented features like ZIL/RAID-Z already implemented.
Btrfs has license advantages as far as linux is concerned (it can
actually go in the main kernel without a rewrite), and it is a bit
more flexible in design and is intended as a general-purpose
filesystem.

Both are definitely the future of file storage compared to ext4, but
they both have a lot of caveats today.

What I would love to see though is something more optimized for flash
like f2fs, but with the feature-completeness and integrity/snapshot
capabilities of btrfs/zfs.  A log-based filesystem is COW by its
nature, so you just need to add that stuff in.

--
Rich