From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gentoo-user+bounces-159524-garchives=archives.gentoo.org@lists.gentoo.org>
Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80])
	by finch.gentoo.org (Postfix) with ESMTP id B70B0138978
	for <garchives@archives.gentoo.org>; Mon, 27 Oct 2014 15:22:42 +0000 (UTC)
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 8CCE6E09A7;
	Mon, 27 Oct 2014 15:22:36 +0000 (UTC)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(No client certificate requested)
	by pigeon.gentoo.org (Postfix) with ESMTPS id 45187E0874
	for <gentoo-user@lists.gentoo.org>; Mon, 27 Oct 2014 15:22:34 +0000 (UTC)
Received: by mail-wi0-f177.google.com with SMTP id ex7so6798523wid.10
        for <gentoo-user@lists.gentoo.org>; Mon, 27 Oct 2014 08:22:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=from:reply-to:to:subject:date:user-agent:references:in-reply-to
         :mime-version:content-type:content-transfer-encoding:message-id;
        bh=AzyazWEs2U2M4Ggfs6PGFKsyJRN32akZ90dexOa3EFk=;
        b=eN7sjoit8UT7ltSgwaYzkuprGLINPm38NXmt2sNA3+UuCtgNbGzjsqS0wB8v3u6Xz4
         9WrUJLaRFfDGXl//qBwwln+A5jfx+XymYaa4HfCTBnL8J3CylXn+sIIDGu+ZdQc4FTPx
         uX/2X40IaqOExvrokpMWgaS6H95a5akPyYwZaHOV7PhGP8vMiQhmS5ZWrSYUIZwEkW4x
         VUk0bYOpuoaiJOi53kchne/gHBQf/sdZRDD9fub5FkH1y5RdJn3+hOocM0jIWzxJCZ82
         8dX3on2shIwCNT3donI7a0lTmmoqbqPvOwkg9Advl3QftuVqUWhGqbfOJkvduvLi+R8m
         7cAw==
X-Received: by 10.180.39.145 with SMTP id p17mr21717937wik.32.1414423353956;
        Mon, 27 Oct 2014 08:22:33 -0700 (PDT)
Received: from dell_xps.localnet (230.3.169.217.in-addr.arpa. [217.169.3.230])
        by mx.google.com with ESMTPSA id wr9sm2768360wjb.42.2014.10.27.08.22.32
        for <gentoo-user@lists.gentoo.org>
        (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
        Mon, 27 Oct 2014 08:22:32 -0700 (PDT)
From: Mick <michaelkintzios@gmail.com>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Safeguarding strategies against SSD data loss
Date: Mon, 27 Oct 2014 15:22:30 +0000
User-Agent: KMail/1.13.7 (Linux/3.16.5-gentoo; KDE/4.12.5; x86_64; ; )
References: <201410270924.40381.michaelkintzios@gmail.com> <544E2875.5000309@gmail.com> <CAGfcS_mbyhQ4hWW20h7g0WmR8Xx5iNVK1dFjSm=pcW9kNrcp4Q@mail.gmail.com>
In-Reply-To: <CAGfcS_mbyhQ4hWW20h7g0WmR8Xx5iNVK1dFjSm=pcW9kNrcp4Q@mail.gmail.com>
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Content-Type: multipart/signed;
  boundary="nextPart2955478.JXQgRZkaGx";
  protocol="application/pgp-signature";
  micalg=pgp-sha256
Content-Transfer-Encoding: 7bit
Message-Id: <201410271522.32452.michaelkintzios@gmail.com>
X-Archives-Salt: 424e4b46-b397-4070-be19-07fd8d53ba87
X-Archives-Hash: e4aea7161d1fb1714fb9a61b58d086f0

--nextPart2955478.JXQgRZkaGx
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

On Monday 27 Oct 2014 13:13:00 Rich Freeman wrote:
> On Mon, Oct 27, 2014 at 7:11 AM, Alan McKinnon <alan.mckinnon@gmail.com>=
=20
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.
> >>=20
> >> On Sunday 26 Oct 2014 23:25:50 Volker Armin Hemmann wrote:
> >>> as others have written already: ssd.
> >>>=20
> >>> With a caveat: if an ssd dies, it will die suddenly. Without a warnin=
g.
> >>> Usually 5 minutes before the start of your weekly or monthly backup
> >>> run. And that is first hand experience.
> >>=20
> >> 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.
> >>=20
> >> 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.
> >=20
> > Without some form of redundancy that would be your best strategy -
> > decent and frequent backups
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
> 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=
=20
have not yet used it on my systems.  Is btrfs agreeable with SSDs, or shoul=
d I=20
be using f2fs:

 http://www.phoronix.com/scan.php?page=3Darticle&item=3Dlinux_314_ssdfs&num=
=3D1

=2D-=20
Regards,
Mick

--nextPart2955478.JXQgRZkaGx
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAABCAAGBQJUTmM4AAoJELAdA+zwE4Ye6ZkIAMIosMpvsbeXhTkDGHsLMegb
4DJuXFWyuQRvizbzjKs3i5Zu0/pG72PDaoeyDL1hrD6cLTWjO6A5+cck4ufDaiUx
XtdaHdmiguc7nYSDPq5TdKoim8gd7CAa76Hd58VDyprK7TA3RiWcZyy8F9sleGyu
DlI6RAnPb2xgGLL/S27k45tfferOvx8tcEULagMZaXYNvtsNimkKAzN4iWYg2RIX
WgpNzYhrf/jPV14PUeJ1jmBba7BjgfO5wwHtNOXQpMS4eaTI7dtnP25dKokvDIzY
zF/Whn3J0K3KO+vThAEqzNl0NJXCEYsyySW2DsSNq2tiSrfMul3d6F6MmYrDmBw=
=6F+n
-----END PGP SIGNATURE-----

--nextPart2955478.JXQgRZkaGx--