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 0FE7E138992 for ; Mon, 27 Oct 2014 17:20:53 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 51F8CE0A5C; Mon, 27 Oct 2014 17:20:48 +0000 (UTC) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 24BEBE09FF for ; Mon, 27 Oct 2014 17:20:46 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id d1so3559670wiv.3 for ; Mon, 27 Oct 2014 10:20:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ogMig797QiNdIyLCdfYEYOID3VQ+xeNK9vvLVEPgW08=; b=CSSTY1Je7aUDtU7vkXjS+rQHPWkTomQn7qHHj1AxXQCnVsI24WNPTc61G6i+KSyJ9O HexdkbARUv9lfIaqlecl8w5c9//KF4ZL5lXOvjnzDNurVIdgKf9lKPQpWqkc3SUNTUfn 19mRXBbJoc+7xvhIIJRrdeeIj3cVq3agDtiAJ6DD8R09x5twrf6I1DzIZeen+z9ctxJ5 E/gGSWmIR2tdaAIn9/34PJGv43GPGpOoUgKi2m1hqUsheBG9t0PmG8/FS8aC21C9kQVi yR8EWZJG2BSMsv8xQslg5bByC8IGhMQLbF39d0IJGfTHr2vEuiot+6l/G1c9Y+tY2vp1 +ttQ== X-Received: by 10.180.212.42 with SMTP id nh10mr21959584wic.52.1414430445695; Mon, 27 Oct 2014 10:20:45 -0700 (PDT) Received: from [192.168.178.21] (p3E9E7622.dip0.t-ipconnect.de. [62.158.118.34]) by mx.google.com with ESMTPSA id hk9sm6470851wjb.46.2014.10.27.10.20.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Oct 2014 10:20:45 -0700 (PDT) Message-ID: <544E7EEB.8010004@googlemail.com> Date: Mon, 27 Oct 2014 18:20:43 +0100 From: Volker Armin Hemmann User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 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 To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] Safeguarding strategies against SSD data loss References: <201410270924.40381.michaelkintzios@gmail.com> <544E2875.5000309@gmail.com> <201410271522.32452.michaelkintzios@gmail.com> In-Reply-To: <201410271522.32452.michaelkintzios@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 14604528-8d57-4832-9312-0d87ad2bdc3b X-Archives-Hash: 80aeb64e429386deec6521d771e35f57 Am 27.10.2014 um 16:22 schrieb Mick: > On Monday 27 Oct 2014 13:13:00 Rich Freeman wrote: >> On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon > wrote: >>> On 27/10/2014 11:24, Mick wrote: >>>> I'm starting a new thread so as to not hijack the one about alternative >>>> kernels, but continue with something Volker raised. >>>> >>>> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote: >>>>> as others have written already: ssd. >>>>> >>>>> With a caveat: if an ssd dies, it will die suddenly. Without a warning. >>>>> Usually 5 minutes before the start of your weekly or monthly backup >>>>> run. And that is first hand experience. >>>> I haven't yet started using SSD and have wondered what sort of a system >>>> should I set up to guard against such instantaneous catastrophic >>>> failures. I am interested to hear what strategies people deploy to >>>> avoid data loss with SSDs, especially on laptops that don't have the >>>> luxury of raid redundancy. >>>> >>>> With spinning drives I use tar and rsync at regular intervals. There >>>> have been a few rare cases where a drive failed without prior notice - >>>> the last one after a reboot. In such cases I am prepared to live with >>>> the risk of some data loss, on machines where raid is not an option. >>> Without some form of redundancy that would be your best strategy - >>> decent and frequent backups >> It isn't the most mature solution, but btrfs send has a lot of >> potential here. One of the main costs of backups is the need to walk >> all the data that you intend to backup to find changes. Rsync can do >> wonders with minimizing bandwidth, and something like duplicity which >> uses librsync can do wonders to minimize the size of serializing that >> in files, but both require reading the entire filesystem. >> >> Btrfs send can serialize a set of changes in the filesystem by reading >> only the btree nodes and extents that have changed. It is fairly >> close to a git pull in that sense, though git doesn't use balanced >> trees. That would greatly reduce the IO cost of frequent backups. >> You would just periodically create a new snapshot, do a send between >> the last snapshot and the new one, and once you've confirmed >> successful completion of that you'd delete the old snapshot. >> >> Of course, IO seeks aren't nearly as expensive on an SSD as they are >> on a hard drive. I haven't really done a lot of rsync on ssds while >> using them so I can't really vouch for how much the IO impacts >> operations. >> >> But yes, backup and RAID are really your only options for SSD failure >> as far as I can see it. That and limiting the amount of data that >> can't be re-generated. If you just save the world file and all of >> /etc you could probably rebuild a Gentoo install fairly quickly on a >> new drive, and then you're just left with /home and whatever else you >> happen to have installed that sticks stuff in /var that you care >> about. > > 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: > > http://www.phoronix.com/scan.php?page=article&item=linux_314_ssdfs&num=1 > neither. Just use ext4. You don't want to combine the sensitive nature of a ssd with the youthful playfulness of a young filesystem. Also, I am a little bit concerned about that 'freshly formatted' at the start of the article.