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 A73951381FA for ; Thu, 29 May 2014 17:57:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 86032E0962; Thu, 29 May 2014 17:57:17 +0000 (UTC) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA256 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A195BE0957 for ; Thu, 29 May 2014 17:57:16 +0000 (UTC) Received: from marcec ([77.22.138.176]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MfF6I-1XDe650m2U-00Oopo for ; Thu, 29 May 2014 19:57:15 +0200 Date: Thu, 29 May 2014 19:57:07 +0200 From: Marc Joliet To: gentoo-amd64@lists.gentoo.org Subject: Re: [gentoo-amd64] Re: btrfs Was: Soliciting new RAID ideas Message-ID: <20140529195707.3fddb0a0@marcec> In-Reply-To: References: <20140527223938.GA3701@sgi.com> <53859043.2050303@thegeezer.net> <20140528223247.66fff7d5@marcec> 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-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; boundary="Sig_/.oe9psxPEPRGyl=vIDyCEpl"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:rXmBU30877/zXbDSAcPb+hrDg7vJWaJoWi/LJqFN8xnXWC05HlH vGzzdujaApKKdUi21uODzchGv/XrVJ7pTgzdQ53311mckKrLL6R3BdY4Y/GIf8IkjaDZKU2 0kuf+jLQki0e6eBldSFMWghrFzYjJbFAs6wrVzqkvNqxcO7+zi4L66r/327hy1cwKbn49ia 7Z62y8wIhwWnd0gpbwGew== X-Archives-Salt: 7acee233-71e0-47b9-9024-1af62caea7a7 X-Archives-Hash: fab91c80fef0a04d571366b7ef19938d --Sig_/.oe9psxPEPRGyl=vIDyCEpl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Thu, 29 May 2014 06:41:14 +0000 (UTC) schrieb Duncan <1i5t5.duncan@cox.net>: > Marc Joliet posted on Wed, 28 May 2014 22:32:47 +0200 as excerpted: >=20 > > (Dammit, it seems that I've developed a habit of writing somewhat > > long-winded emails :-/ . Sorry!) >=20 > You? What does that make mine? =3D:^) Novels, duh ;-) . > > Am Wed, 28 May 2014 08:29:07 +0100 schrieb thegeezer > > : > >=20 > >> top man, thanks for detail and the tips ! > >=20 > > I second this :) . In fact, I think I'll link to it in my btrfs thread > > on gentoo-user. >=20 > Thanks. I was on the user list for a short time back in 2004 when I=20 > first started with gentoo, but back then it was mostly x86, while my=20 > interest was amd64, and the amd64 list was active enough back then that I= =20 > didn't really feel the need for the mostly x86 user list, so I=20 > unsubscribed and never got around to subscribing again, when the amd64=20 > list traffic mostly dried up. But if it'll help people there... go right= =20 > ahead and link or repost. I ended up simply forwarding it, as opposed to bumping my inactive thread. > (Also, anyone who wants to put it up on the=20 > gentoo wiki, go ahead. I work best on newsgroups and mailing lists, and= =20 > find wikis, like most of the web, in practice read-only for my usage. =20 > I'll read up on them, but somehow never get around to actually writing=20 > anything on them, even if it would in theory save me a bunch of time=20 > since I could write stuff once and link it instead of repeating on the=20 > lists.) Heh, the only Wiki I ever edited was at my old student job. But yeah, I do= n't feel comfortable enough in my BTRFS knowledge to write a Wiki entry myself. > > 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: > >=20 > > How does btrfs handle checksum errors on a single drive (or when > > self-healing fails)? > >=20 > > That is, does it return a hard error, rendering the file unreadable, or > > is it possible to read from a corrupted file? >=20 > As you suspect, it's a hard error. Damn >:-( . > There has been developer discussion on the btrfs list of some sort of=20 > mount option or the like that would allow retrieval even with bad=20 > checksums, presumably with dmesg then being the only indication something= =20 > was wrong, in case it's a simple single bit-flip or the like in something= =20 > like text where it should be obvious, or media, where it'll likely not=20 > even be noticed, but I've not seen an actual patch for it. Presumably=20 > it'll eventually happen, but to now there's a lot more potential features= =20 > and bug fixes to code up than developers and time in their days to code=20 > them, so no idea when. I guess when the right person gets that itch to=20 > scratch. That's really too bad, I guess this isn't a situation that often arises for BTRFS users. > Which is yet another reason I have chosen the raid1 mode for both data=20 > and metadata and am eagerly awaiting the N-way-mirroring code in ordered= =20 > to let me do 3-way as well, because I'd really /hate/ to think it's just= =20 > a bitflip, yet not have any way at all to get to it. >=20 > Which of course makes it that much more critical to keep your backups as= =20 > current as you're willing to risk losing, *AND* test that they're=20 > actually recoverable, as well. Of course, but like I said, I can't back up this one data partition. I do = have backups for everything on my desktop computer, though, which are on the oth= er partition of this external drive. > (FWIW here, while I do have backups, they aren't always current. Still,= =20 > for my purposes the *REAL* backups are the experiences and knowledge in=20 > my head. As long as I have that, I can recreate the real valuable stuff,= =20 > and to the extent that I can't, I don't consider it /that/ valuable. And= =20 > if I lose those REAL backups... well I won't have enough left then to=20 > realize what I've lost, will I? That's ultimately the attitude I take,=20 > appreciating the real important stuff for what it is, and the rest, well,= =20 > if it comes to it, I lose what I lose, but yes, I do still keep backups,= =20 > actually multiple levels deep, tho as I said they aren't always current.) Hehe, good philosophy :-) . > However, one trick that I alluded to, that actually turned out to be an=20 > accidental side effect feature of fixing an entirely different problem,=20 > is setting mixed-blockgroup mode at mkfs.btrfs and selecting dup mode for= =20 > both data and metadata at that time as well. (In mixed-mode, data and=20 > metadata must be set the same, and the default except on ssd is then dup,= =20 > but the point here is to ensure dup, not single.) As I said, the reason= =20 > mixed-mode is there is to deal with really small filesystems and it's the= =20 > default for under a gig. And there's definitely a performance cost as=20 > well as the double-space cost when using dup. But it *DOES* allow one to= =20 > run dup mode for both data and metadata, and some users are willing to=20 > pay its performance costs for the additional data integrity it offers. =20 That is an interesting idea. I might consider that. Or I might just creat= e a third partition and make a RAID 1 out of those, once I know how much space = my backups will ultimately take. But really, why is there no dup for data? (I only set up my backups about a month ago just before my migration to BTR= FS, using rsnapshot, and the backups aren't fully there yet; the one monthly ba= ckup is still missing, and I wanted to wait a bit after that to see how much spa= ce the backups ultimately require. Plus, I might back up (parts of) my laptop= to there, too, although there isn't that much stuff on it that isn't already synchronised in some other fashion, so it's not decided yet.) > Certainly, if you can possibly do two devices, the paired device raid1=20 > mode is preferable, but for instance my netbook has only a single SATA=20 > port, so either mixed-bg and dup mode, or partitioning up and using two=20 > partitions to fake two devices for raid1 mode, are what I'm likely to do. [...] Ah, you mentioned the RAID 1 idea already :-) . --=20 Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup --Sig_/.oe9psxPEPRGyl=vIDyCEpl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJTh3T5AAoJEL/Q5oYsiHj0NusQAKZhSa2DbKDe3X19XBVyDpA3 5JfZysm5r/ebN2qVy/9O2aQS0DRxf7C2myt7gLw786rsyIcvLxPpJ8Zteqdc1sQA b7P9ekCqKi+HkWu4WZUYnEstwUK8a/V59bjXzce9OMl7ThTWdTQiZyKd0mjShI65 KxvcEmNbL2gpWMT932CSeB1zTxf/FuhBPghabXDmd4rAst0lG5mszwP6tFGmzwO0 kiacxdojNGm7KGgR94CFwGiphShRCuw0YwkFn/Vz/QcTZne0e8xvSzzTG8kcnsVr bPlqn6o93vaunfhSHhj/PDH/+AW4Y0Q14I5LAhVKlA4+DcXvB3YhtOSAqmffmkEa gWWbxiI7SFox0vOrFulorMZZtF3HdM8vs0+KYgqOxc/Tx1ng1OQk+54shkrUaeuW juX6b4orDyA/BTGTHN+LgIPQfag34rWZ7UfprZmK5TzQAZqYvTG0ECgzxV9aBE3r ygcySqj4FjsIwmfxpcBecYMfFdaoOTCl29MHO3qoeAaK+t6C2QXto/UwMZq1yeDL eggQGgYME7aZw4iRGs5qFcdrgTJXJ1aHxfaFXqpPbLUve6nUJ2WxaOZSZA/ilsTq 0d2QbwttLKuYlDMBWHQ4UGGc0mcz/QgJhjYSdjLUieHQTF8RXH+Av5sdrwLff04g BoBPQkF1Igo2oLhhpi5o =K3e3 -----END PGP SIGNATURE----- --Sig_/.oe9psxPEPRGyl=vIDyCEpl--