From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 16E80138994 for ; Mon, 27 Oct 2014 17:31:17 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 46BC8E0A7D; Mon, 27 Oct 2014 17:30:55 +0000 (UTC) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 19EB5E0A5F for ; Mon, 27 Oct 2014 17:30:53 +0000 (UTC) Received: by mail-qg0-f47.google.com with SMTP id i50so4327298qgf.6 for ; Mon, 27 Oct 2014 10:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=7mCAYGIAOzxUrAKMxkg9rRpFJGjh3EnjvPlQZ86okdc=; b=smDK+49xdCCbPaPXtc6lhvS5GdBBw8s+uGHKSr4f8WwQXUVl62UyzU4JpM/qZTRwmh 6fdLMpR0JX7ksLD26n+H6EX8r/+8+XW8TdOgYLAsbS+Wl8pG4GiopvSFLkeRdf4ifjNY eUcgMgWBi1LvK8LzpPVeiZ1CoCkzc8LIhopvz0NiJL//h73LiX3CXNcmDkqnLrUh6pTb OUz9e/Jlgozzo1gYA066cAfTImYFlJmYPkXb+mfBkAyhLyiI1LaJzU4fl5GQrpi9fK68 +GepdFQjlC0ng3uLFQ696/WvYfKd5KdtuPb73AD6S0nApGhCKz3AAhbG0JWnyWy0b4NR MENQ== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.229.7.133 with SMTP id d5mr35406394qcd.24.1414431050444; Mon, 27 Oct 2014 10:30:50 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.140.102.134 with HTTP; Mon, 27 Oct 2014 10:30:50 -0700 (PDT) In-Reply-To: References: <201410270924.40381.michaelkintzios@gmail.com> <544E2875.5000309@gmail.com> <201410271522.32452.michaelkintzios@gmail.com> Date: Mon, 27 Oct 2014 13:30:50 -0400 X-Google-Sender-Auth: NmbBCjlK21JAwZ-53LV8smw6uHc Message-ID: Subject: Re: [gentoo-user] Safeguarding strategies against SSD data loss From: Rich Freeman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 47ba9a06-786d-4cd0-8571-bd7f74743f5c X-Archives-Hash: 8a615d24765a0d27f996429712d76e57 On Mon, Oct 27, 2014 at 12:52 PM, Pandu Poluan 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