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 C5AA31381FA for ; Thu, 29 May 2014 06:41:37 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CB20EE0883; Thu, 29 May 2014 06:41:35 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 129B3E087E for ; Thu, 29 May 2014 06:41:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Wpu1t-0007WI-2n for gentoo-amd64@lists.gentoo.org; Thu, 29 May 2014 08:41:33 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 May 2014 08:41:33 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 May 2014 08:41:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: btrfs Was: Soliciting new RAID ideas Date: Thu, 29 May 2014 06:41:14 +0000 (UTC) Message-ID: References: <20140527223938.GA3701@sgi.com> <53859043.2050303@thegeezer.net> <20140528223247.66fff7d5@marcec> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.140 (Chocolate Salty Balls; GIT 2ae6aff /usr/src/portage/src/egit-src/pan2) X-Archives-Salt: 42026a65-a9b0-452a-b1a2-76058c01853e X-Archives-Hash: 507d9c12f5daa7d086265fe4225f7fe0 Marc Joliet posted on Wed, 28 May 2014 22:32:47 +0200 as excerpted: > (Dammit, it seems that I've developed a habit of writing somewhat > long-winded emails :-/ . Sorry!) You? What does that make mine? =:^) > Am Wed, 28 May 2014 08:29:07 +0100 schrieb thegeezer > : > >> top man, thanks for detail and the tips ! > > I second this :) . In fact, I think I'll link to it in my btrfs thread > on gentoo-user. Thanks. I was on the user list for a short time back in 2004 when I first started with gentoo, but back then it was mostly x86, while my interest was amd64, and the amd64 list was active enough back then that I didn't really feel the need for the mostly x86 user list, so I unsubscribed and never got around to subscribing again, when the amd64 list traffic mostly dried up. But if it'll help people there... go right ahead and link or repost. (Also, anyone who wants to put it up on the gentoo wiki, go ahead. I work best on newsgroups and mailing lists, and find wikis, like most of the web, in practice read-only for my usage. I'll read up on them, but somehow never get around to actually writing anything on them, even if it would in theory save me a bunch of time since I could write stuff once and link it instead of repeating on the lists.) > I do have a question for Duncan (or anybody else who knows, but I know > that Duncan is fairly active on the BTRFS ML), though: > > How does btrfs handle checksum errors on a single drive (or when > self-healing fails)? > > That is, does it return a hard error, rendering the file unreadable, or > is it possible to read from a corrupted file? As you suspect, it's a hard error. There has been developer discussion on the btrfs list of some sort of mount option or the like that would allow retrieval even with bad checksums, presumably with dmesg then being the only indication something was wrong, in case it's a simple single bit-flip or the like in something like text where it should be obvious, or media, where it'll likely not even be noticed, but I've not seen an actual patch for it. Presumably it'll eventually happen, but to now there's a lot more potential features and bug fixes to code up than developers and time in their days to code them, so no idea when. I guess when the right person gets that itch to scratch. Which is yet another reason I have chosen the raid1 mode for both data and metadata and am eagerly awaiting the N-way-mirroring code in ordered to let me do 3-way as well, because I'd really /hate/ to think it's just a bitflip, yet not have any way at all to get to it. Which of course makes it that much more critical to keep your backups as current as you're willing to risk losing, *AND* test that they're actually recoverable, as well. (FWIW here, while I do have backups, they aren't always current. Still, for my purposes the *REAL* backups are the experiences and knowledge in my head. As long as I have that, I can recreate the real valuable stuff, and to the extent that I can't, I don't consider it /that/ valuable. And if I lose those REAL backups... well I won't have enough left then to realize what I've lost, will I? That's ultimately the attitude I take, appreciating the real important stuff for what it is, and the rest, well, if it comes to it, I lose what I lose, but yes, I do still keep backups, actually multiple levels deep, tho as I said they aren't always current.) However, one trick that I alluded to, that actually turned out to be an accidental side effect feature of fixing an entirely different problem, is setting mixed-blockgroup mode at mkfs.btrfs and selecting dup mode for both data and metadata at that time as well. (In mixed-mode, data and metadata must be set the same, and the default except on ssd is then dup, but the point here is to ensure dup, not single.) As I said, the reason mixed-mode is there is to deal with really small filesystems and it's the default for under a gig. And there's definitely a performance cost as well as the double-space cost when using dup. But it *DOES* allow one to run dup mode for both data and metadata, and some users are willing to pay its performance costs for the additional data integrity it offers. Certainly, if you can possibly do two devices, the paired device raid1 mode is preferable, but for instance my netbook has only a single SATA port, so either mixed-bg and dup mode, or partitioning up and using two partitions to fake two devices for raid1 mode, are what I'm likely to do. (I actually don't know which I'll do as I haven't messed with the netbook in awhile, but I have an SSD already laying around to throw in it and I keep thinking about it, and with its single SATA port, it's a perfect example of sometimes not being /able/ to run two devices. OTOH, I might just throw some money at it and buy a full 64-bit replacement machine, thus allowing me to use the 64-bit packages I build for my main machine on the (new) little one too, and thus to do away with the 32-bit chroot on my main machine that I use as a built image for the netbook.) (I snipped it there to reply to this bit first as it was a straightforward answer. I'll go back and read the rest now, to see if there's anything else I want to reply to.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman