1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Have you tried ZFS? The kernel modules are in the portage tree and I |
5 |
am maintaining a FAQ regarding the status of Gentoo ZFS support at github: |
6 |
|
7 |
https://github.com/gentoofan/zfs-overlay/wiki/FAQ |
8 |
|
9 |
Data stored on ZFS is generally safe unless you go out of your way to |
10 |
lose it (e.g. put the ZIL/SLOG on a tmpfs). |
11 |
|
12 |
On 02/24/12 18:26, Duncan wrote: |
13 |
> Rich Freeman posted on Fri, 24 Feb 2012 13:47:45 -0500 as |
14 |
> excerpted: |
15 |
> |
16 |
>> On Fri, Feb 24, 2012 at 1:43 PM, Alexis Ballier |
17 |
>> <aballier@g.o> wrote: |
18 |
>>> moreover the && wont delete the lib if revdep-rebuild failed i |
19 |
>>> think, so it should be even safer to copy/paste :) |
20 |
> |
21 |
> FWIW this is the preserved_libs feature/bug I ran into in early |
22 |
> testing, that convinced me to turn it off. Running revdep-rebuild |
23 |
> manually was far safer anyway, since at least then I /knew/ the |
24 |
> status of various libs, they weren't preserved on first run, then |
25 |
> arbitrarily deleted on second, even if it still broke remaining |
26 |
> depending apps to do so. |
27 |
> |
28 |
> So if that was reliably fixed, I'd be FAR happier about enabling |
29 |
> FEATURES=preserved-libs. I'm not sure I actually would as I like a |
30 |
> bit more direct knowledge of stale libs on the system than the |
31 |
> automated handling gives me, but at least I'd not have to worry |
32 |
> about the so-called "preserved" libs STILL disappearing and leaving |
33 |
> broken packages, if I DID enable it! |
34 |
> |
35 |
> So definitely ++ on this! =:^) |
36 |
> |
37 |
>> Am I the only paranoid person who moves them rather than |
38 |
>> unlinking them? Oh, if only btrfs were stable... |
39 |
> |
40 |
> FWIW, in the rare event it breaks revdep-rebuild or the underlying |
41 |
> rebuilding itself, I rely on my long set FEATURES=buildpkg and |
42 |
> emerge -K. In the even rarer event that too is broken, there's |
43 |
> always manual untarring of the missing lib from the binpkg (I've |
44 |
> had to do that once when gcc itself was broken due to an unadvised |
45 |
> emerge -C that I knew might break things given the depclean |
46 |
> warning, but also knew I could fix with an untar if it came to it, |
47 |
> which it did), or if it comes to it, booting to backup and using |
48 |
> ROOT= to emerge -K back to the working system. |
49 |
> |
50 |
> |
51 |
> [btrfs status discussion, skip if uninterested.] |
52 |
> |
53 |
> I'm not sure if that's a reference to the btrfs snapshots allowing |
54 |
> rollbacks feature, or a hint that you're running it and worried |
55 |
> about its stability underneath you... |
56 |
> |
57 |
> If it's the latter, you probably already know this, but if it's the |
58 |
> former, and for others interested... |
59 |
> |
60 |
> I recently set the btrfs kernel options and merged btrfs-progs, |
61 |
> then read up on the wiki and joined the btrfs list, with the plan |
62 |
> being to get familiar with it and perhaps install it. |
63 |
> |
64 |
> From all the reports about it being an option for various distros, |
65 |
> etc, now, and all the constant improvement reports, I had /thought/ |
66 |
> that the biggest issue for stability was the lack of an |
67 |
> error-correcting (not just detecting) fsck.btrfs, and that the |
68 |
> restore tool announced late last year, that allows pulling data off |
69 |
> of unmountable btrfs volumes was a reasonable workaround. |
70 |
> |
71 |
> What I found, even allowing for the fact that such lists get the |
72 |
> bad reports and not the good ones, thus paint a rather worse |
73 |
> picture of the situation than actually exists for most users, is |
74 |
> that... |
75 |
> |
76 |
> BTRFS still has a rather longer way to go than I had thought. It's |
77 |
> still FAR from stable, even for someone like myself that often runs |
78 |
> betas and was prepared to keep (and use, if necessary) TESTED |
79 |
> backups, etc. Maybe by Q4 this year, but also very possibly not |
80 |
> until next year. I'd definitely NOT recommend that anyone run it |
81 |
> now, unless you are SPECIFICALLY running it for testing and bug |
82 |
> reporting purposes with "garbage" data (IOW, data that you're NOT |
83 |
> depending on, at the btrfs level, at all) that you are not only |
84 |
> PREPARED to lose, but EXPECT to lose, perhaps repeatedly, during |
85 |
> your testing. |
86 |
> |
87 |
> IOW, there's still known untraced and unfixed active data |
88 |
> corruption bugs remaining. Don't put your data on btrfs at this |
89 |
> point unless you EXPECT to have it corrupted, and want to actively |
90 |
> help in tracing and patching the problems! |
91 |
> |
92 |
> Additionally, for anyone who has been interested in the btrfs RAID |
93 |
> capacities, striped/raid0 it handles, but its raid1 and raid10 |
94 |
> capacities are misnamed. At present, it's strictly two-way-mirror |
95 |
> ONLY, there's no way to do N-way (N>2) mirroring aside from |
96 |
> layering on top of say mdraid, at all, and of course layering on |
97 |
> top of mdraid loses the data integrity guarantees at that level, |
98 |
> btrfs still has just the one additional copy it can fall back on. |
99 |
> This SERIOUSLY limits btrfs data integrity possibilities in a 2+ |
100 |
> drive failure scenario. |
101 |
> |
102 |
> btrfs raid5/6 isn't available yet, but the current roadmap says |
103 |
> kernels 3.4 or 3.5. Multi-mirror is supposed to be built on that |
104 |
> code, tho the mentions of it I've seen are specifically |
105 |
> triple-mirror, so it's unclear whether arbitrary N-way (N>3) |
106 |
> mirroring as in true raid1 will be possible even then. But whether |
107 |
> triple-way specifically or N-way (N>=3), given it's on top of |
108 |
> raid5/6, to be introduced in 3.4/3.5, triple-way mirroring thus |
109 |
> appears to be 3.5/3.6 at the earliest. |
110 |
> |
111 |
> So while I had gotten the picture that btrfs was stabilizing and it |
112 |
> was mostly over-cautiousness keeping that experimental label |
113 |
> around, that's definitely NOT the case. Nobody should really plan |
114 |
> on /relying/ on it, even with backups, until at least late this |
115 |
> year, and very possibly looking at 2013 now. |
116 |
> |
117 |
> So btrfs is still a ways out. =:^( |
118 |
> |
119 |
> Meanwhile, for anyone that's still interested in it at this point, |
120 |
> note that the homepage wiki currently listed the btrfs-progs |
121 |
> package is a stale copy on kernel.org, still read-only after the |
122 |
> kernel.org breakin. The "temporary" but looking more and more |
123 |
> permanent location is: |
124 |
> |
125 |
> http://btrfs.ipv5.de/index.php?title=Main_Page |
126 |
> |
127 |
> Also, regarding the gentoo btrfs-progs package, see my recently |
128 |
> filed: |
129 |
> |
130 |
> https://bugs.gentoo.org/show_bug.cgi?id=405519 |
131 |
> |
132 |
|
133 |
-----BEGIN PGP SIGNATURE----- |
134 |
Version: GnuPG v2.0.18 (GNU/Linux) |
135 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ |
136 |
|
137 |
iQIcBAEBAgAGBQJPSDQNAAoJELFAT5FmjZuEeeQP/2clR9eIz34lm1oQNwW1/Ad7 |
138 |
+Yl1KTjWo9w3B/KqV6qla/SZs22OnD6X7PqYS3hTYwBLTMAM5uQmSGJ5z+Ju+rka |
139 |
gbox4nQujaYFfqPMuxi5VEKc8n+k9WJG2nWUvfT7MlRvft8jZexn6p0ehrNOWdB+ |
140 |
7kNsqkjJLFwWBpLdJJh9oVDTYymTb82Iujrj82ZOWROc41i4+nd2PR5dC5Qd2xWq |
141 |
bRzwGxppBymTQHaDQG9zYzBQzISBre/agQB/ZM58xutV6S8fHO5o277J5EDFF6+w |
142 |
pWA0COylTyfT13E3MJOhluhP5dag52FVNtr9SGCb0s5vb1njxJI3J4IxgLwwA6U8 |
143 |
Uz4+PAQYMQz40n65yjtyh9D+kvmUIJzZgrWZL0fMEa93ka/i+4cnjYcqCPKd7WzN |
144 |
ONv0yRCDmArVIJZJ2snqlInUTLPKr6PRIYWaO2pQnL/ZsMec9dm6DHeviQ6ywrat |
145 |
SEuZ4dbjv6/CE2zstK5mfxrhH6x0+gWSJoEKlfuQYI7a984kqNd4VzCfawBLBbuT |
146 |
W1PLbUWLbAJ/4Xr//7De6+m8OjTBRt9gEkQFTYbpjl5nmBV3qLB1u4xG91aCXoxr |
147 |
QPwcL4ZNH3paGjiLFG7O8uFLPLon6aF0szLGMcPlewkYU7lJ9KgHz+KIu5588xXD |
148 |
//u/5USHYjnIwDJFSmNW |
149 |
=lusE |
150 |
-----END PGP SIGNATURE----- |