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 B70B0138978 for ; 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 ; Mon, 27 Oct 2014 15:22:34 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id ex7so6798523wid.10 for ; 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 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 27 Oct 2014 08:22:32 -0700 (PDT) From: Mick 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> In-Reply-To: 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 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 = =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--