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 |