1 |
On 12/06/13 16:23, Duncan wrote: |
2 |
> wireless posted on Fri, 06 Dec 2013 14:31:52 -0500 as excerpted: |
3 |
|
4 |
>> btrfs in the handbook? |
5 |
>> |
6 |
>> So, these are the sections that would need only limited prose to support |
7 |
>> btrfs in the handbook: |
8 |
>> |
9 |
>> 2.b 4.b/4.d 4.e 6.a 6.b 7.b 8.a 9.e 10.e ? |
10 |
>> |
11 |
>> The idea would be to use a single 2T drive, with the standard (handbook) |
12 |
>> 3 partition scheme, with just the simplest gentoo system set up with |
13 |
>> BTRFS. |
14 |
|
15 |
What I'm thinking is just "cut and paste" the handbook somewhere |
16 |
and clearly mark the sections where the handbook has been modified |
17 |
(deviated from) for this btrfs experiment. |
18 |
|
19 |
|
20 |
>> Your comments and suggestions are most welcome. If this idea is deemed |
21 |
>> meritorious, I'll take a crack at it and post what I discover after |
22 |
>> performing a few of this proposed btrfs handbook installs? |
23 |
> |
24 |
> As you'll know if you follow the btrfs list, have read the wiki, or even |
25 |
> simply the btrfs kernel config option, btrfs isn't exactly stable yet. |
26 |
> While a patch in 3.13 does tone down the warning a bit, matching a |
27 |
> slightly toned down warning on the wiki of late, and I /do/ run btrfs |
28 |
> here, it's still far enough from stable that I'd hesitate to put it in |
29 |
> the handbook just yet. |
30 |
|
31 |
Yes, I have a hack of btrfs running on old hardware. I'm going to |
32 |
hack out a handbook_similar doc and try to explicitly follow it |
33 |
noting in detail any discussion or other reference sources where |
34 |
warranted. |
35 |
|
36 |
|
37 |
> Basically, current btrfs status for single-device or multi-device |
38 |
> raid0/1/10 modes is "semi-stable"; it generally works reasonably well, |
39 |
> but be *SURE* and keep *TESTED* backups and be prepared to use them if |
40 |
> necessary, AND try to keep on latest (upstream Linus) stable kernel if |
41 |
> not the development kernel RCs. Following current discussions and status |
42 |
> on the btrfs list is recommended as well. |
43 |
> |
44 |
> And bugs do still often affect a reasonable cross-section of users, too. |
45 |
> One fixed in 3.12 was hitting a lot of systemd users as well as others |
46 |
> using pre-allocated files that are then written into (torrent clients |
47 |
> often do this too and someone reported getting hit by that, too). For |
48 |
> 3.13, a host of kernel memory leaks have been fixed, as well as a |
49 |
> concurrency bug hit when people tried to run a balance and a snapshot (as |
50 |
> often done via cronjob, so the admin may have only been thinking about |
51 |
> and run the balance manually) at the same time. |
52 |
> |
53 |
> Until very recently, live-git master-branch btrfs-progs was strongly |
54 |
> recommended too (development happens in branches and the policy for |
55 |
> master is that it's always run-ready, as stable as btrfs itself is at |
56 |
> this point), but with kernel 3.12 the btrfs-progs versioning policy |
57 |
> changed, with releases now generally synced with the kernel and versioned |
58 |
> similarly, thus making btrfs-progs-3.12 as current as the 3.12 series |
59 |
> kernel. Of course that's ~arch, while live-git 9999 is naturally masked. |
60 |
> |
61 |
> Run older than that as a btrfs tester (which is what anyone running btrfs |
62 |
> is at this point, a tester) and you're not only needlessly risking having |
63 |
> to use those backups you're keeping as a not-yet-fully-stable filesystem |
64 |
> tester due to running code with known and now fixed bugs, but any testing |
65 |
> reports filed aren't going to be as useful either, because you're testing |
66 |
> old code on a fast-moving project that has moved on from it. |
67 |
|
68 |
Agreed with all of the above. |
69 |
|
70 |
> But a lot of gentoo users reading the handbook won't want to be upgrading |
71 |
> that fast nor will they be that faithful in keeping current and tested |
72 |
> backups, nor will they wish to bother with following the btrfs list, as |
73 |
> recommended for anyone wishing to test btrfs at this point. |
74 |
|
75 |
Hmmmmm, |
76 |
|
77 |
I understand your concerns. The goals is to do this now, to flesh out, |
78 |
the issues, so when btrfs becomes "stable" there is a simple guide |
79 |
for adventurous, but ordinary users to follow. Also, a dual hope that |
80 |
supporting btrfs, formally in the handbook, become a reality. |
81 |
|
82 |
I think most folks are ready for a file system beyond ext4, particularly |
83 |
for a second (gentoo) system. Some distros are actively supporting btrfs. |
84 |
|
85 |
|
86 |
|
87 |
> Oh, and neither btrfs nor zfs mount options are listed in the mount |
88 |
> manpage yet. I don't know about zfs, but one indication of btrfs |
89 |
> maturing will be when it appears in the mount manpage. |
90 |
|
91 |
I disagree. When btrfs is found in SystemRescue and many, many places |
92 |
on the net, it became serious. Waiting for something to appear properly |
93 |
in the manpages, is a very odd semantic as an acceptable standard for |
94 |
use, imho: |
95 |
http://www.phoronix.com/scan.php?page=news_item&px=MTQ2NTY |
96 |
|
97 |
> So IMO btrfs is inappropriate for the handbook at this point. Or if it's |
98 |
> included, stress its testing aspect and that those choosing to test it |
99 |
> should be prepared to use their TESTED backups, keep current on the |
100 |
> kernel and btrfs-progs, and follow the btrfs list to keep up with current |
101 |
> issues with what they've chosen to test. |
102 |
|
103 |
YES, it's about being ready; not about being a laggard, imho: |
104 |
https://help.ubuntu.com/community/btrfs |
105 |
|
106 |
> Tho the thinking is that btrfs should really start to stabilize in 2014, |
107 |
> at least for the "basic" functionality comparable to most filesystems. |
108 |
> Of course in some ways every year seems to be the year btrfs will |
109 |
> stabilize, rather reminding me of the year of the Linux desktop. |
110 |
> However, I know it's getting closer, as I'm actually running it this |
111 |
> year, something I tried but gave up on last year. And after leaving it |
112 |
> to mature a bit after the first bit, I could DEFINITELY see the |
113 |
> difference when I came back. It really is getting there, and 2014 could |
114 |
> very well be the year. |
115 |
> |
116 |
> Meanwhile, zfs is a bit more mature, but as you point out, has licensing |
117 |
> issues, thus making it not particularly handbook appropriate, tho of |
118 |
> course people can choose to run it if they wish. |
119 |
> |
120 |
> Thus at this point, ext4 really remains the best "mainline" choice, with |
121 |
> xfs also a reasonable choice these days. And reiserfs certainly remains |
122 |
> usable. I'm still using it on spinning rust here, tho it's not so good |
123 |
> for SSDs, which is where I'm testing btrfs. But ext4 has an ssd mode as |
124 |
> well, I believe. |
125 |
|
126 |
|
127 |
Nothing in this effort will replace ext4, except most gentoo user, are |
128 |
by the nature of being gentoo users, way_ready for a new, feature rich |
129 |
file system. Ext4 is ARCANE, but very stable. |
130 |
|
131 |
So what I'm thinking is getting some space on wiki.gentoo.org for this |
132 |
effort? I'd do most of the work and have a few_folks look over the |
133 |
original content enhancements ensuring that my |
134 |
discoveries/ideas/workarounds are reasonable. I do not wish to imply |
135 |
that it is any sort of official handbook effort, but having some of the |
136 |
gentoo-doc folks look in, time to time, would be keen. |
137 |
|
138 |
One thing I'm not sure of, is which section should it go under? |
139 |
|
140 |
Project & Community ? |
141 |
|
142 |
Surely not core? |