From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (unknown [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id E90E91381FA for ; Mon, 12 May 2014 14:31:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A0C17E0AF9; Mon, 12 May 2014 14:30:59 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 697A5E09D7 for ; Mon, 12 May 2014 14:30:58 +0000 (UTC) Received: from marcec ([77.22.138.176]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0Mhdex-1WOayx3SnT-00MwFc for ; Mon, 12 May 2014 16:30:56 +0200 Date: Mon, 12 May 2014 16:30:49 +0200 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] btrfs conversion: first impressions Message-ID: <20140512163049.4f605ff0@marcec> In-Reply-To: <536FEA92.1080502@xunil.at> References: <20140506121832.678ae781@marcec> <5369688C.1040708@iinet.net.au> <20140507015126.5b57fb88@marcec> <536B712E.3040009@iinet.net.au> <536BC974.9090200@xunil.at> <536D339D.9000506@xunil.at> <536E0A01.4070803@xunil.at> <536F6EA2.6030506@xunil.at> <536FA2A4.4040205@xunil.at> <536FEA92.1080502@xunil.at> X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) 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; micalg=pgp-sha1; boundary="Sig_/NguEiXq3MWy=wuwvn6E6u_R"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:KGIQtogfmHqAj8ZvIhC3g/bwF5d3CcsWVQeEJ0Z3mzuU4s0mGlz y2sq7BZDSTXGJIuvcVesKA7tdt5a84cWPZLr6tBkpYmxXBDk0yUOyadCEYgPO4NtarWeQb9 C+ISu7AydeJ0qiuhTJ/Rj6IzbzFkIWq2ESamip9r4R/rviLQyMFMbR3q0xaR2k/Boka6AY6 n7gH9+bKbMmMvd60FSXZQ== X-Archives-Salt: aa88a233-25de-4e47-8548-2e6a4996c7f4 X-Archives-Hash: 003b498e28d082d1127db0dad135e443 --Sig_/NguEiXq3MWy=wuwvn6E6u_R Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Sun, 11 May 2014 23:24:34 +0200 schrieb "Stefan G. Weichinger" : [...] > ... but it is really nice-to-have the option to snapshot your root-fs, > do-something-to-it (emerge unstable stuff, delete the wrong files, you > name it ...), and if you don't like it you simply boot using your > snapshot ... that is actually really helpful and also rather easy once > you get your head wrapped around the concepts and the few steps > necessary (and it's quick: the snapshot is done in a blink ...) In a presentation by Donny Berkholz at Fosdem this year [0], he mentioned t= he distro CoreOS, and that they can do atomic updates. I haven't looked it up = in detail, but they're website says that they use a dual-root scheme where the update is performed in a second root, which is made the real root after rebooting or after a kexec [1]. It seems to me that this could be made simp= ler and easier with btrfs snapshots. > As far as I researched btrfs seems to be quite reliable in a not too > complex (read: multi devices) setup ... and backups never hurt anyway. Of course, for me one of *the* big features was the capability to automatic= ally fix corrupted data (the self-healing features of btrfs). This is only possi= ble when you have redundancy across multiple devices. (I'm running a scrub right now.) But even with a single device, you can at least *detect* corruption, I just want to also be able to have it automatically *corrected*. > As I do backups all the time I feel quite confident to test my setups > for the next few days and maybe even completely overhaul my desktop setup. Ditto :) . As risky as it is, this was also a "test" of my backup, in the sense that, while I knew the backups looked okay by manual inspection, I hadn't actually restored from backup yet. Obviously, it worked :) . > -> 2x 1TB HDDs plus 1x 256GB SSD (plus the one older 80GB SSD for tests > right now) ... with LVM and stuff (remember my hassles last week with > the LVMs not activated??) ... I could run one btrfs-pool on the 2 HDDs > and one on the SSD and cut all of my various filesystems out of that. >=20 > Would mixing hdds and the ssd into one pool make sense? I think, no ... ? I suspect something like bcache would work (except I remember reading that btrfs does not work with it yet). > -- >=20 > I will also test running VMs on btrfs-subvolumes and doing snapshots: >=20 > snapshot the underlying subvolume, apply some changes within the VM and > then rollback to the snapshot. >=20 > This would remove LVM-snapshotting out of the way ... etc etc >=20 > As mentioned before, looking forward ... and curious! I'm glad I motivated some people to try btrfs themselves :) . [0] https://www.youtube.com/watch?v=3DegjcVGKwnrw [1] http://coreos.com/using-coreos/updates/ (section "technical details") --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/NguEiXq3MWy=wuwvn6E6u_R Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTcNseAAoJEL/Q5oYsiHj0CBUQALDGtvkvXn1cwlwa02qTic+S 0jr5pro4g+fiDGH/lhh715ngzG0J4B+L5lMU6ApD4VEnHj0Y/55k0RmM6LmategK VBytZoXmarreMwEYxYLSX/RInjUX/+q1fgQcWCCFRnCTHcLoWQKJEPw+nu7DWAao 84+IgWJv/lCYKbt6kK08D9VEczXQSmI3iFPwizpY0rwczEkuFbWbkgdmoLS1UDsT jk+S866L9dHLVDwfr/2MZbhnjFTAfZC846CSN2ApUBjwuMHr04Epl4Y+d/QWWBZs 2eMgpL7vV8cJ9kR58XHsF3A5KW5piAgAJAKQQO1nyKLx8lQy8aTQgVbvi05Yl9Wd TsUHcfcJmAmGRo4cIGOguufyOVAbvBQUY/khKaF17QoPNNPNFrKKuzGn+zgwok7D dZN6oXfcIwbZLcie0FhExUe+3oclJq3d0XKPOf6Ap19AfBWojSJkHHfgJWKU6t4e MnUyiWiWE+z+cDQiqT9MaYDELauSW/SuX8YWqRI8R5ZAMFl5ODlAceaYixXRkLmr 1+yqbJuqUHcNcY/XcclZLvbVDFKrAmaknvSw+nD/JNa83qjO5vCqYxkFrHyLjmbb kDx4+TLUrjMhe4KtCdRGmiFk6yfLrpg5KZY8kr/69jHzSrI6be8jHBzkUdeKqJZP M6muB2+ZUYJXBVym+zSx =k7ez -----END PGP SIGNATURE----- --Sig_/NguEiXq3MWy=wuwvn6E6u_R--