Gentoo Archives: gentoo-amd64

From: Marc Joliet <marcec@×××.de>
To: gentoo-amd64@l.g.o
Subject: Re: [gentoo-amd64] Re: btrfs Was: Soliciting new RAID ideas
Date: Thu, 29 May 2014 17:57:19
Message-Id: 20140529195707.3fddb0a0@marcec
In Reply to: [gentoo-amd64] Re: btrfs Was: Soliciting new RAID ideas by Duncan <1i5t5.duncan@cox.net>
1 Am Thu, 29 May 2014 06:41:14 +0000 (UTC)
2 schrieb Duncan <1i5t5.duncan@×××.net>:
3
4 > Marc Joliet posted on Wed, 28 May 2014 22:32:47 +0200 as excerpted:
5 >
6 > > (Dammit, it seems that I've developed a habit of writing somewhat
7 > > long-winded emails :-/ . Sorry!)
8 >
9 > You? <looking this way and that> What does that make mine? =:^)
10
11 Novels, duh ;-) .
12
13 > > Am Wed, 28 May 2014 08:29:07 +0100 schrieb thegeezer
14 > > <thegeezer@×××××××××.net>:
15 > >
16 > >> top man, thanks for detail and the tips !
17 > >
18 > > I second this :) . In fact, I think I'll link to it in my btrfs thread
19 > > on gentoo-user.
20 >
21 > Thanks. I was on the user list for a short time back in 2004 when I
22 > first started with gentoo, but back then it was mostly x86, while my
23 > interest was amd64, and the amd64 list was active enough back then that I
24 > didn't really feel the need for the mostly x86 user list, so I
25 > unsubscribed and never got around to subscribing again, when the amd64
26 > list traffic mostly dried up. But if it'll help people there... go right
27 > ahead and link or repost.
28
29 I ended up simply forwarding it, as opposed to bumping my inactive thread.
30
31 > (Also, anyone who wants to put it up on the
32 > gentoo wiki, go ahead. I work best on newsgroups and mailing lists, and
33 > find wikis, like most of the web, in practice read-only for my usage.
34 > I'll read up on them, but somehow never get around to actually writing
35 > anything on them, even if it would in theory save me a bunch of time
36 > since I could write stuff once and link it instead of repeating on the
37 > lists.)
38
39 Heh, the only Wiki I ever edited was at my old student job. But yeah, I don't
40 feel comfortable enough in my BTRFS knowledge to write a Wiki entry myself.
41
42 > > I do have a question for Duncan (or anybody else who knows, but I know
43 > > that Duncan is fairly active on the BTRFS ML), though:
44 > >
45 > > How does btrfs handle checksum errors on a single drive (or when
46 > > self-healing fails)?
47 > >
48 > > That is, does it return a hard error, rendering the file unreadable, or
49 > > is it possible to read from a corrupted file?
50 >
51 > As you suspect, it's a hard error.
52
53 Damn >:-( .
54
55 > There has been developer discussion on the btrfs list of some sort of
56 > mount option or the like that would allow retrieval even with bad
57 > checksums, presumably with dmesg then being the only indication something
58 > was wrong, in case it's a simple single bit-flip or the like in something
59 > like text where it should be obvious, or media, where it'll likely not
60 > even be noticed, but I've not seen an actual patch for it. Presumably
61 > it'll eventually happen, but to now there's a lot more potential features
62 > and bug fixes to code up than developers and time in their days to code
63 > them, so no idea when. I guess when the right person gets that itch to
64 > scratch.
65
66 That's really too bad, I guess this isn't a situation that often arises for
67 BTRFS users.
68
69 > Which is yet another reason I have chosen the raid1 mode for both data
70 > and metadata and am eagerly awaiting the N-way-mirroring code in ordered
71 > to let me do 3-way as well, because I'd really /hate/ to think it's just
72 > a bitflip, yet not have any way at all to get to it.
73 >
74 > Which of course makes it that much more critical to keep your backups as
75 > current as you're willing to risk losing, *AND* test that they're
76 > actually recoverable, as well.
77
78 Of course, but like I said, I can't back up this one data partition. I do have
79 backups for everything on my desktop computer, though, which are on the other
80 partition of this external drive.
81
82 > (FWIW here, while I do have backups, they aren't always current. Still,
83 > for my purposes the *REAL* backups are the experiences and knowledge in
84 > my head. As long as I have that, I can recreate the real valuable stuff,
85 > and to the extent that I can't, I don't consider it /that/ valuable. And
86 > if I lose those REAL backups... well I won't have enough left then to
87 > realize what I've lost, will I? That's ultimately the attitude I take,
88 > appreciating the real important stuff for what it is, and the rest, well,
89 > if it comes to it, I lose what I lose, but yes, I do still keep backups,
90 > actually multiple levels deep, tho as I said they aren't always current.)
91
92 Hehe, good philosophy :-) .
93
94 > However, one trick that I alluded to, that actually turned out to be an
95 > accidental side effect feature of fixing an entirely different problem,
96 > is setting mixed-blockgroup mode at mkfs.btrfs and selecting dup mode for
97 > both data and metadata at that time as well. (In mixed-mode, data and
98 > metadata must be set the same, and the default except on ssd is then dup,
99 > but the point here is to ensure dup, not single.) As I said, the reason
100 > mixed-mode is there is to deal with really small filesystems and it's the
101 > default for under a gig. And there's definitely a performance cost as
102 > well as the double-space cost when using dup. But it *DOES* allow one to
103 > run dup mode for both data and metadata, and some users are willing to
104 > pay its performance costs for the additional data integrity it offers.
105
106 That is an interesting idea. I might consider that. Or I might just create a
107 third partition and make a RAID 1 out of those, once I know how much space my
108 backups will ultimately take.
109
110 But really, why is there no dup for data?
111
112 (I only set up my backups about a month ago just before my migration to BTRFS,
113 using rsnapshot, and the backups aren't fully there yet; the one monthly backup
114 is still missing, and I wanted to wait a bit after that to see how much space
115 the backups ultimately require. Plus, I might back up (parts of) my laptop to
116 there, too, although there isn't that much stuff on it that isn't already
117 synchronised in some other fashion, so it's not decided yet.)
118
119 > Certainly, if you can possibly do two devices, the paired device raid1
120 > mode is preferable, but for instance my netbook has only a single SATA
121 > port, so either mixed-bg and dup mode, or partitioning up and using two
122 > partitions to fake two devices for raid1 mode, are what I'm likely to do.
123 [...]
124
125 Ah, you mentioned the RAID 1 idea already :-) .
126
127 --
128 Marc Joliet
129 --
130 "People who think they know everything really annoy those of us who know we
131 don't" - Bjarne Stroustrup

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-amd64] Re: btrfs Was: Soliciting new RAID ideas Rich Freeman <rich0@g.o>