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 715B71381FA for ; Tue, 6 May 2014 23:51:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BC509E092C; Tue, 6 May 2014 23:51:37 +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 7EC6FE07F0 for ; Tue, 6 May 2014 23:51:36 +0000 (UTC) Received: from marcec ([77.22.138.176]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lh7PL-1XE4yP413P-00oaLG for ; Wed, 07 May 2014 01:51:35 +0200 Date: Wed, 7 May 2014 01:51:26 +0200 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] planned btrfs conversion: questions Message-ID: <20140507015126.5b57fb88@marcec> In-Reply-To: <5369688C.1040708@iinet.net.au> References: <20140506121832.678ae781@marcec> <5369688C.1040708@iinet.net.au> 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_/+.6GiM.o7hvgzbfeQUHVUZH"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:978qm0J2MwiKnKddK7ovWoqvwVoTTgcdLA11B2RtFDgUvIYqyUd oRV5PfJm1ZT5Rn3bt+i8NxfBkaFqfcOHgft6BsMJm1eIfnuP6IHjEgoD5P5gLVks5YgrGAz gcxDkGDsB0nT3qEtXaRvrHhfs7oNV4xeVN6LOVHgtpHo92UCtGwo15QsZakFoLi5bXq97Zg wjeFG4hXN1IIuAYvZ9lLg== X-Archives-Salt: 0fdfb01f-ea1a-4b20-b963-cf053eb15081 X-Archives-Hash: bb38ca69f23006195783247966bd13aa --Sig_/+.6GiM.o7hvgzbfeQUHVUZH Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Wed, 07 May 2014 06:56:12 +0800 schrieb William Kenworthy : > On 05/06/14 18:18, Marc Joliet wrote: > > Hi all, > >=20 > > I've become increasingly motivated to convert to btrfs. From what I've= seen, > > it has become increasingly stable; enough so that it is apparently supp= osed to > > become the default FS on OpenSuse in 13.2. > >=20 > > I am motivated by various reasons: > .... >=20 > My btrfs experience: >=20 > I have been using btrfs seriously (vs testing) for a while now with > mixed results but the latest kernel/tools seem to be holding up quite wel= l. >=20 > ~ 2yrs on a Apple/gentoo laptop (I handed it back to work a few months > back) - never a problem! (mounted with discard/trim) That's one HDD, right? From what I've read, that's the most tested and stab= le use case for btrfs, so it doesn't surprise me that much that it worked so w= ell. > btrfs on a 128MB intel ssd (linux root drive) had to secure reset a few > times as btrfs said the filesystem was full, but there was 60G+ free - > happens after multiple crashes and it seemed the btrfs metadata and the > ssd disagreed on what was actually in use - reset drive and restore from > backups :( Now running ext4 on that drive with no problems - will move > back to btrfs at some point. All the more reason to stick with EXT4 on the SSD for now. [snip interesting but irrelevant ceph scenario] >=20 > 3 x raid 0+1 (btrfs raid 1 with 3 drives) - working well for about a month That last one is particularly good to know. I expect RAID 0, 1 and 10 to wo= rk fairly well, since those are the oldest supported RAID levels.=20 > ~10+ gentoo VM's, one ubuntu and 3 x Win VM's with kvm/qemu storage on > btrfs - regular scrubs show an occasional VM problem after system crash > (VM server), otherwise problem free since moving to pure btrfs from > ceph. Gentoo VM's were btrfs in raw qemu containers and are now > converted to qcow2 - no problems since moving from ceph. Fragmentation > on VM's is a problem but "cp --reflink vm1 vm2" for vm's is really > really cool! That matches the scenario from the ars technica article; the author is a hu= ge fan of file cloning in btrfs :) . And yeah, too bad autodefrag is not yet stable. > I have a clear impression that btrfs has been incrementally improving > and the current kernel and recovery tools are quite good but its still > possible to end up with an unrecoverable partition (in the sense that > you might be able to get to some of the the data using recovery tools, > but the btrfs mount itself is toast) >=20 > Backups using dirvish - was getting an occasional corruption (mainly > checksum) that seemed to coincide with network problems during a backup > sequence - have not seen it for a couple of months now. Only lost whole > partition once :( Dirvish really hammers a file system and ext4 usually > dies very quickly so even now btrfs is far better here. I use rsnapshot here with an external hard drive formatted to EXT4. I'm not *that* worried about the FS dying, more that it dies at an inopportune mome= nt where I can't immediately restore it. [again, snip interesting but irrelevant ceph scenario] >=20 > I am slowly moving my systems from reiserfs to btrfs as my confidence in > it and its tools builds. I really dislike ext4 and its ability to lose > valuable data (though that has improved dramaticaly) but it still seems > better than btrfs on solid state and hard use - but after getting burnt > I am avoiding that scenario so need to retest. Rising confidence: good to hear :) . Perhaps this will turn out similarly to when I was using the xf86-video-ati release candidates and bleeding edge gentoo-sources/mesa/libdrm/etc. (for 3D support in the r600 driver): I start using it shortly before it starts truly stabilising :) . --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/+.6GiM.o7hvgzbfeQUHVUZH Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTaXWFAAoJEL/Q5oYsiHj01u0QAMhr19R2WGPhFsfH05klFGDX mJyArFe5PljAZkHCkUBcN+ZkHtf4rJuoAlFl0fXuRNTEPztnxWmPBYW2hi54kJli ZNC9Vxw94ExMlRFt0u/m3p4BHwMjB09Azcr+ay51rcuiqb5rMnmrvDbFK3+UyPBr SG6Mwwmkgn3kF4i9Z4286QqZvZYgxOxZdH0bGRMOIW6kb6zAjBufjql+MCrg2oJw BObwKzNXnnBqiifGUunf7omXrrRPj1MQQnWyJNF4lH/ZJGc/U3NmVbbdrPOxlmHZ C7hKq3ySXi7qjiRF9t3065enoDZOmSrIymkuFvXnURx3pkCFc+mrsnevASosEw6/ 9Ryqd99AY3ErHCTQmaJGHpES+dH4EWZrT4QHZaRygPoT3aJ/RGk7zCnpoQHghujc 0wnA2dt39qtT6Zc4c834NiJiwBQFTHQEluhI3aSMX2muisaKC+4CgukRjNF01DD4 kgnbSsrVM9xUFCUPeTL14FxNaumqsiSGIyeLoQxjpfHRoMVoxvgg/xF3Q0niHLo0 jdsEw+TrYq6GxoJHtaoiBEA9Q7HxBj9zOC+tmssjV+WPJubCP7WknIOLkKGE/pzi MAg3qvxr8+R135n2k7Z5PGjr1othgCNyrOdrpLXwv3VcFiwfzbBkSYUHFrtTRErs YgzfgPMMYaIjXGX35Sl5 =mPKB -----END PGP SIGNATURE----- --Sig_/+.6GiM.o7hvgzbfeQUHVUZH--