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 E3F631381FA for ; Thu, 8 May 2014 20:43:44 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 21197E09E0; Thu, 8 May 2014 20:43:39 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D6126E0984 for ; Thu, 8 May 2014 20:43:37 +0000 (UTC) Received: from marcec ([77.22.138.176]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0Ld0jY-1X8jEG0iOW-00iAJZ for ; Thu, 08 May 2014 22:43:36 +0200 Date: Thu, 8 May 2014 22:43:28 +0200 From: Marc Joliet To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] planned btrfs conversion: questions Message-ID: <20140508224328.4ee40e84@marcec> In-Reply-To: <536B712E.3040009@iinet.net.au> References: <20140506121832.678ae781@marcec> <5369688C.1040708@iinet.net.au> <20140507015126.5b57fb88@marcec> <536B712E.3040009@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_/a3Pn69Bx6slP0yfa862KsYO"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:i5xzK3wudXATlJXvf8rxKOnUXWFlPiWHHDC4BXuUG5u9uPNHcLP 6mGXgLPkplCTg+zffZYVUQGjbNo850Qk5H23gz9YIQuHQRDdxaEiRs4/aOOreKsDFwrTpfL +tXONCr1sI+68P33wjGY7a5FXq+ZwFy5Kl1mfk7GdFJZOKHEyMPk7Ql2Whb1cLr8srfMm8H +C7zUpGnEUVp9Olgh1VCg== X-Archives-Salt: be1cfcb3-5dd2-44d1-a6d4-3fb8c81be0e0 X-Archives-Hash: 7347bf2292c32e5063290acebee2c79c --Sig_/a3Pn69Bx6slP0yfa862KsYO Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 08 May 2014 19:57:34 +0800 schrieb William Kenworthy : > On 05/07/14 07:51, Marc Joliet wrote: > > Am Wed, 07 May 2014 06:56:12 +0800 > > schrieb William Kenworthy : > > > >> On 05/06/14 18:18, Marc Joliet wrote: > >>> Hi all, > >>> > >>> 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 su= pposed to > >>> become the default FS on OpenSuse in 13.2. > >>> > >>> I am motivated by various reasons: > >> .... > >> > >> My btrfs experience: > >> > >> 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 = well. > >> > >> ~ 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 = stable > > use case for btrfs, so it doesn't surprise me that much that it worked = so well. > > > Yes, light duty using the builtin ssd chips on the motherboard. SSD chips on the motherboard? I just did a quick googled (well, "duckduckwe= nt" would be more accurate; funny how language works), do you mean something li= ke the Intel Z68 chipset? > >> 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 fr= om > >> 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. > I have had had very poor luck with ext anything and would hesitate it to > recommend it except for this very specific case where there is little > alternative - reiserfs is far better on platters for instance. I, like Stefan, am interested in precisely what kind of negative experiences you've had with ext*. I used to use reiserfs (from waaay back when I still used SuSE), but the on= ly remnant of that is a broken external HDD that I want to attempt a ddrescue = on someday (really the only reason I still keep around reiserfs support in my kernel). The only thing I really miss is tail packing of small files; my ac= tual disk usage grew noticeably after my switch to ext4. But ext* have the disti= nct advantage of being used pretty much everywhere, which, as we all know, is an important factor in finding bugs. Reiserfs, in comparison, is AFAIK unmaintained now (of course, it's maintained in the sense that the existing code is kept working, but that's beside the point). > > [snip interesting but irrelevant ceph scenario] > Its relevant because it keeps revealing bugs in btrfs by stressing it - > one of those reported by me to ceph was reported upstream by the ceph > team and fixed last year - bugs still exist in btrfs ! Sorry, I read "ceph" and immediately thought "OK, clustering file system, w= ay outside of experience" and didn't realise you were talking about outright b= ugs in btrfs (I kind of assumed a situation similar to btrfs and swap files: one piece of software (e.g., the kernel swap code) making assumptions that don't hold for btrfs). > >> 3 x raid 0+1 (btrfs raid 1 with 3 drives) - working well for about a m= onth > > That last one is particularly good to know. I expect RAID 0, 1 and 10 t= o work > > fairly well, since those are the oldest supported RAID levels. > > > >> ~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 huge > > fan of file cloning in btrfs :) . > > > > And yeah, too bad autodefrag is not yet stable. > Not that its not stable but that it cant deal with large files that > change randomly on a continual basis like VM virtual disks. Oh, I thought it was still considered new and "unpolished" (I did not mean buggy!). > >> 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) > >> > >> 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 who= le > >> partition once :( Dirvish really hammers a file system and ext4 usual= ly > >> 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 = moment > > where I can't immediately restore it. > > > > [again, snip interesting but irrelevant ceph scenario] > as I said above - if it fails under ceph, its likely going to fail under > similar stresses using other software - I am not talking ceph bugs (of > which there are many) but actual btrfs corruption. Got it, thanks! > >> 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. (f= or 3D > > support in the r600 driver): I start using it shortly before it starts = truly > > stabilising :) . > > > More exposure, more bugs will surface and be fixed - its getting there. I sure hope so, I'll be making the switch either tomorrow or Monday :-) . > BillK --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/a3Pn69Bx6slP0yfa862KsYO Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTa+x0AAoJEL/Q5oYsiHj0LzcQALkvV4NC27esv9yXibvloJJl KouR3AI6DjBCsxwET2GoePsv7a8pynBvyjGydUh+c4H08Q3pL0TV62hb15zyMWLN U3EGTjuPNHIjCZfl/dOcinlgkIRYW7Kv8eovr7/BnChxWgO5w1JpSDM+Pb0VGcMp 4Rjm+nlqtBdr2Qk8wC0390rdEP9M1b87yuSz1YGitLaOcLYUO9GsJS5mHOCF2RjS M3l41knmyilSw3w2cjkc55Vfca3q2ptfSsdPwkUIugT3LlMVtuBI00dXIHpxhV0V +RuqTRCF5ekl98cjCQZKEuAAJ26Zz3s+5g1uVBLDHhFR+79zr4rOyqsw+tGUgct8 +3skKZlMPePX8nBjYSa5dqeAL7T2rCOI1xTgaVoALc24A4ECyiH1xd1zeExF1o3B ReZO9CZoLloT/IojMA2lf5JpsY8SpB8ZnPhiO3HOlpLspbiyyA/biEgzkULgFHd7 e9RvaUV4JevhAu28Z0BkBkJEfO3sZZT5YqY9FJHflSZD+/njUrPfN3hDO8zimST8 PPV1pKlhfwF3WVfFJsO/0XnU2g1+RGkqEfLt3d8DxGOI8wIMKkIW7lYZgS+pDaz1 t0C/ntp/RfaLOMbiZ2JkjLdyk0NDk770ObemKCMCmGIajEhCpyg+2buakkOVCoXg 1T1of+4ZZZUkHhoMQ2iJ =HY0c -----END PGP SIGNATURE----- --Sig_/a3Pn69Bx6slP0yfa862KsYO--