11:24 a.m.
Hey all,
Over the last few months (since Fedora 22 beta's release), I've been using
Btrfs as my daily driver filesystem across a multitude of machines. After
Fedora 22 released, I tried it with RAID 5 and RAID 6 enabled on a few
machines with fantastic success (there aren't even any scary warnings about
being experimental anymore!).
Admittedly, my tests have been specific to my needs (media center storage,
workstations, laptops with SSDs, etc.), but it appears to work really well
now.
Also, with kernel 4.1 imported into rawhide, we've now got performance
improvements for large (>20TB) filesystems (though it's been plenty fast
for my 48TB array).
As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
the default in Fedora 23
<https://lists.fedoraproject.org/pipermail/devel/2014-October/203058.html>;.
At this point, I'm personally convinced that it is certainly ready and
doable for F23.
Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.
The question now is: as a distribution, where are we on this? The tools
seem to work, the filesystem appears stable, and I've not been able to
cause the filesystem to corrupt itself with any kind of user error or cause
it to keel over. So, what's left?
--
真実はいつも一つ！/ Always, there's only one truth!
12:30 p.m.
Neal Gompa <ngompa13 <at> gmail.com> writes:
As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
becoming
the default in Fedora 23. At this point, I'm personally convinced that
it is
certainly ready and doable for F23.
Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.
I asked about this recently on #fedora-devel (I was the one who asked
originally on this list) and was told there are no plans to make it the
default yet. It's amazing that it was originally planned to be the default
on F16 (see https://fedoraproject.org/wiki/Btrfs ). But I don't want to see
data loss, and not knowing much about filesystems, am sticking to the default.
12:41 p.m.
On Tue, Jun 23, 2015 at 1:30 PM, Andre Robatino
<robatino(a)fedoraproject.org> wrote:
Neal Gompa <ngompa13 <at> gmail.com> writes:
> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
the default in Fedora 23. At this point, I'm personally convinced that it is
certainly ready and doable for F23.
>
> Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.
I asked about this recently on #fedora-devel (I was the one who asked
originally on this list) and was told there are no plans to make it the
default yet. It's amazing that it was originally planned to be the default
on F16 (see https://fedoraproject.org/wiki/Btrfs ). But I don't want to see
Someone created a wiki page proposing that. It was never actually
planned to be the default.
josh
1:38 p.m.
On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa <ngompa13(a)gmail.com> wrote:
As I recall, Josef Bacik mentioned that he'd be pushing for
Btrfs
becoming the default in Fedora 23
<https://lists.fedoraproject.org/pipermail/devel/2014-October/203058.html>
. At this point, I'm personally convinced that it is certainly ready and
doable for F23.
Well actually he said his "plan" was to push for F23. I've been using
btrfs raid 6 for several years now and have been lucky I haven't
encountered any issues - but if you subscribe to the mailing list you'll
see others haven't been quite as lucky. I'm sure he'll propose it once he
believes it is ready. When proposing a default change it is prudent to be
cautious. In the meantime it's there to use for early adopters; and the
more people who test the faster issues will be identified and corrected.
Just be sure you've taken the proper precautions.... ;-)
3:15 p.m.
On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa <ngompa13(a)gmail.com> wrote:
> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
> becoming the default in Fedora 23
> <https://lists.fedoraproject.org/pipermail/devel/2014-October/203058.html>
>
> . At this point, I'm personally convinced that it is certainly ready and
> doable for F23.
>
Well actually he said his "plan" was to push for F23. I've been using
btrfs raid 6 for several years now and have been lucky I haven't
encountered any issues - but if you subscribe to the mailing list you'll
see others haven't been quite as lucky. I'm sure he'll propose it once he
believes it is ready. When proposing a default change it is prudent to be
cautious. In the meantime it's there to use for early adopters; and the
more people who test the faster issues will be identified and corrected.
Just be sure you've taken the proper precautions.... ;-)
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Certainly, but with none of the features in Btrfs actually emitting scary
"experimental" warnings anymore, and even all features working in btrfs
RAID 5/6 now, I think we should really start pushing it to more people. Or
at least develop some kind of test plan to prove the "worthiness" of using
it as default. We must have something, ne?
--
真実はいつも一つ！/ Always, there's only one truth!
3:20 p.m.
On 23 June 2015 at 14:15, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox <gbcox(a)bzb.us>
wrote:
>
>
> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>>
>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
>> becoming the default in Fedora 23
>>
>> . At this point, I'm personally convinced that it is certainly ready and
>> doable for F23.
>
>
> Well actually he said his "plan" was to push for F23. I've been using
> btrfs raid 6 for several years now and have been lucky I haven't encountered
> any issues - but if you subscribe to the mailing list you'll see others
> haven't been quite as lucky. I'm sure he'll propose it once he believes
it
> is ready. When proposing a default change it is prudent to be cautious. In
> the meantime it's there to use for early adopters; and the more people who
> test the faster issues will be identified and corrected. Just be sure
> you've taken the proper precautions.... ;-)
>
>
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Certainly, but with none of the features in Btrfs actually emitting scary
"experimental" warnings anymore, and even all features working in btrfs RAID
5/6 now, I think we should really start pushing it to more people. Or at
least develop some kind of test plan to prove the "worthiness" of using it
as default. We must have something, ne?
So if there are problems who is going to deal with the users, diagnose
the issues and fix them? Those are going to be the people who will
need to push for this feature if they think it is ready or not. I
would start by finding out who they are, talking with them and then
looking at what time frame they think the feature would be ready.
--
Stephen J Smoogen.
7:40 p.m.
On Tue, Jun 23, 2015 at 4:20 PM, Stephen John Smoogen <smooge(a)gmail.com>
wrote:
On 23 June 2015 at 14:15, Neal Gompa <ngompa13(a)gmail.com>
wrote:
> On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
>>
>>
>> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>>>
>>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
>>> becoming the default in Fedora 23
>>>
>>> . At this point, I'm personally convinced that it is certainly ready
and
>>> doable for F23.
>>
>>
>> Well actually he said his "plan" was to push for F23. I've been
using
>> btrfs raid 6 for several years now and have been lucky I haven't
encountered
>> any issues - but if you subscribe to the mailing list you'll see others
>> haven't been quite as lucky. I'm sure he'll propose it once he
believes it
>> is ready. When proposing a default change it is prudent to be
cautious. In
>> the meantime it's there to use for early adopters; and the more people
who
>> test the faster issues will be identified and corrected. Just be sure
>> you've taken the proper precautions.... ;-)
>>
>>
>> --
>> devel mailing list
>> devel(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/devel
>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
>
>
> Certainly, but with none of the features in Btrfs actually emitting scary
> "experimental" warnings anymore, and even all features working in btrfs
RAID
> 5/6 now, I think we should really start pushing it to more people. Or at
> least develop some kind of test plan to prove the "worthiness" of using
it
> as default. We must have something, ne?
>
So if there are problems who is going to deal with the users, diagnose
the issues and fix them? Those are going to be the people who will
need to push for this feature if they think it is ready or not. I
would start by finding out who they are, talking with them and then
looking at what time frame they think the feature would be ready.
--
Stephen J Smoogen.
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
That is precisely why I'm asking on this list. I don't know who those
people are, and this is really the best place I know of to start contact
and those discussions.
--
真実はいつも一つ！/ Always, there's only one truth!
8:07 p.m.
On 23 June 2015 at 18:40, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Jun 23, 2015 at 4:20 PM, Stephen John Smoogen
<smooge(a)gmail.com>
wrote:
>
> On 23 June 2015 at 14:15, Neal Gompa <ngompa13(a)gmail.com> wrote:
> > On Tue, Jun 23, 2015 at 2:38 PM, Gerald B. Cox <gbcox(a)bzb.us> wrote:
> >>
> >>
> >> On Tue, Jun 23, 2015 at 9:24 AM, Neal Gompa <ngompa13(a)gmail.com>
wrote:
> >>>
> >>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
> >>> becoming the default in Fedora 23
> >>>
> >>> . At this point, I'm personally convinced that it is certainly
ready
> >>> and
> >>> doable for F23.
> >>
> >>
> >> Well actually he said his "plan" was to push for F23. I've
been using
> >> btrfs raid 6 for several years now and have been lucky I haven't
> >> encountered
> >> any issues - but if you subscribe to the mailing list you'll see others
> >> haven't been quite as lucky. I'm sure he'll propose it once he
> >> believes it
> >> is ready. When proposing a default change it is prudent to be
> >> cautious. In
> >> the meantime it's there to use for early adopters; and the more people
> >> who
> >> test the faster issues will be identified and corrected. Just be sure
> >> you've taken the proper precautions.... ;-)
> >>
> >>
> >> --
> >> devel mailing list
> >> devel(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/devel
> >> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
> >
> >
> > Certainly, but with none of the features in Btrfs actually emitting
> > scary
> > "experimental" warnings anymore, and even all features working in
btrfs
> > RAID
> > 5/6 now, I think we should really start pushing it to more people. Or at
> > least develop some kind of test plan to prove the "worthiness" of
using
> > it
> > as default. We must have something, ne?
> >
>
> So if there are problems who is going to deal with the users, diagnose
> the issues and fix them? Those are going to be the people who will
> need to push for this feature if they think it is ready or not. I
> would start by finding out who they are, talking with them and then
> looking at what time frame they think the feature would be ready.
That is precisely why I'm asking on this list. I don't know who those people
are, and this is really the best place I know of to start contact and those
discussions.
My apologies.. my tone was not helpful. You are correct that asking
here is where to start. I think the groups who would be able to help
answer would be
1. Kernel team
2. QA team
3. Anaconda team
4. Workstation/Server/Cloud or just one if it were to be only on one product.
--
Stephen J Smoogen.
10:28 p.m.
On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
Certainly, but with none of the features in Btrfs actually emitting
scary
"experimental" warnings anymore, and even all features working in btrfs RAID
5/6 now, I think we should really start pushing it to more people. Or at
least develop some kind of test plan to prove the "worthiness" of using it
as default. We must have something, ne?
Bingo! We need
a. Pass/fail performance criteria
b. Pass/fail data loss criteria
c. Pass/fail security criteria
and code to drive them all. My area of expertise is strictly
performance. I'd be happy to contribute tests and analysis, although I
suspect Phoronix may have everything needed.
Let's say a three-way bakeoff - btrfs, ext4 and xfs (since IIRC xfs is
a default in some RHEL configurations). Let me know if you want me to
resurrect any of my 2009 stuff on disk performance.
--
OSJourno: Robust Power Tools for Digital Journalists
http://www.znmeb.mobi/stories/osjourno-robust-power-tools-for-digital-jou...
Remember, if you're traveling to Bactria, Hump Day is Tuesday and Thursday.
2:42 a.m.
On 24 June 2015 at 04:28, M. Edward (Ed) Borasky <znmeb(a)znmeb.net> wrote:
On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa
<ngompa13(a)gmail.com> wrote:
> Certainly, but with none of the features in Btrfs actually emitting scary
> "experimental" warnings anymore, and even all features working in btrfs
RAID
> 5/6 now, I think we should really start pushing it to more people. Or at
> least develop some kind of test plan to prove the "worthiness" of using it
> as default. We must have something, ne?
Bingo! We need
a. Pass/fail performance criteria
b. Pass/fail data loss criteria
c. Pass/fail security criteria
And advice for end users on btrfs management. People trying it out
already are going to be more enthusiastic about understanding
filesystems than the typical user. Also considering whether anything
will be broken by the change, for example, df reporting inaccurate
numbers may have knock on effects.
--
imalone
http://ibmalone.blogspot.co.uk
5:43 a.m.
On Tue, Jun 23, 2015 at 9:07 PM, Stephen John Smoogen <smooge(a)gmail.com>
wrote:
On 23 June 2015 at 18:40, Neal Gompa <ngompa13(a)gmail.com>
wrote:
>
>
> That is precisely why I'm asking on this list. I don't know who those
people
> are, and this is really the best place I know of to start contact and
those
> discussions.
>
>
My apologies.. my tone was not helpful. You are correct that asking
here is where to start. I think the groups who would be able to help
answer would be
1. Kernel team
2. QA team
3. Anaconda team
4. Workstation/Server/Cloud or just one if it were to be only on one
product.
I suspect that engaging every one of those would probably be the right way
to go, since we need to figure out suitability across the board as the
default. Every group would have different criteria, which is why we have
differing filesystem defaults across the board now.
On Tue, Jun 23, 2015 at 11:28 PM, M. Edward (Ed) Borasky <znmeb(a)znmeb.net>
wrote:
On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa
<ngompa13(a)gmail.com> wrote:
> Certainly, but with none of the features in Btrfs actually emitting scary
> "experimental" warnings anymore, and even all features working in btrfs
RAID
> 5/6 now, I think we should really start pushing it to more people. Or at
> least develop some kind of test plan to prove the "worthiness" of using
it
> as default. We must have something, ne?
Bingo! We need
a. Pass/fail performance criteria
b. Pass/fail data loss criteria
c. Pass/fail security criteria
and code to drive them all. My area of expertise is strictly
performance. I'd be happy to contribute tests and analysis, although I
suspect Phoronix may have everything needed.
Let's say a three-way bakeoff - btrfs, ext4 and xfs (since IIRC xfs is
a default in some RHEL configurations). Let me know if you want me to
resurrect any of my 2009 stuff on disk performance.
Fedora does have Phoronix's test suite in our repositories, so that can be
used for performance tests, but additional specific tests may be of value
too.
I'm not sure how to test for security. As far as I know, encryption is
usually handled by other tools underneath the filesystem (LUKS/dm-crypt) or
above it (ecryptfs).
A design for data integrity tests would probably be a good idea. A
coworker of mine at my day job and I did some ad-hoc tests with fio in our
spare time to test Btrfs' capabilities on RAID 56 with a multi-disk Btrfs
filesystem and yanked disks, faking damage and replacement to see how the
system recovered using the functions available. From our ad-hoc tests, it
looked pretty damn good. I could talk to him and see if we could formalize
it a bit and bring it to Fedora for use in data integrity tests. But it may
not be enough, so perhaps other folks have some ideas here on data
integrity tests?
On Wed, Jun 24, 2015 at 3:42 AM, Ian Malone <ibmalone(a)gmail.com> wrote:
On 24 June 2015 at 04:28, M. Edward (Ed) Borasky
<znmeb(a)znmeb.net> wrote:
> On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
>
>> Certainly, but with none of the features in Btrfs actually emitting
scary
>> "experimental" warnings anymore, and even all features working in
btrfs
RAID
>> 5/6 now, I think we should really start pushing it to more people. Or at
>> least develop some kind of test plan to prove the "worthiness" of
using
it
>> as default. We must have something, ne?
>
> Bingo! We need
>
> a. Pass/fail performance criteria
> b. Pass/fail data loss criteria
> c. Pass/fail security criteria
>
And advice for end users on btrfs management. People trying it out
already are going to be more enthusiastic about understanding
filesystems than the typical user. Also considering whether anything
will be broken by the change, for example, df reporting inaccurate
numbers may have knock on effects.
I would be happy to help with that. In fact, I actually gave a talk on
Btrfs and using it
<http://files.meetup.com/13432052/mtg2015-06-03-intro-to-btrfs.pdf> at my
local Linux Users' Group in Norwalk, CT and helped other people there to
start using it. Developing a plan and documentation on how to use Btrfs
effectively is probably a good idea.
--
真実はいつも一つ！/ Always, there's only one truth!
1:18 p.m.
On Tue, Jun 23, 2015 at 9:07 PM, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On 23 June 2015 at 18:40, Neal Gompa <ngompa13(a)gmail.com>
wrote:
> That is precisely why I'm asking on this list. I don't know who those people
> are, and this is really the best place I know of to start contact and those
> discussions.
>
>
My apologies.. my tone was not helpful. You are correct that asking
here is where to start. I think the groups who would be able to help
answer would be
1. Kernel team
The Fedora kernel team is fairly tired of having this same
conversation every release[1]. Progress is certainly being made
upstream and it is encouraging to see issues get fixed. However, most
of the same points we brought up last time this was discussed still
exist. So in the interest of being clear, our official position is
that we would not recommend btrfs as the default filesystem in any
Fedora Edition. Here are a few reasons why.
1) The upstream maintainers (primarily Josef) have repeatedly said
[2][3] btrfs is not ready to be default and that they would advocate
for a change when btrfs is ready. That has not happened.
2) The Fedora kernel team does not have extensive knowledge or
expertise available to debug btrfs issues. While this is generally
true for a lot of the kernel subsystems, we do have expertise
available to us for ext4 and XFS. We tend to value user data very
highly, and having additional filesystem developers readily available
to help fix issues found in Fedora is extremely important to us.
3) The level of effort around btrfs in Fedora outside of our team is
fairly limited. We have a few people plugging away at testing and
reporting upstream, which is excellent to see and should be encourage.
Some may suggest this is a chicken and egg situation, but btrfs has
been available as a general filesystem choice on install since F16.
None of the features people seem to want from btrfs have been further
integrated into the distro at all. Things like backup/restore via
snapshot, update/rollback via snapshot, etc have no distro level
integration at all. The btrfs-progs and Snapper packages are in the
repository, but that is about it.
4) As mentioned before, the filesystem is general available for those
that wish to use it. It is an installation choice in the installer.
Considering some of the above points, it is not immediately clear why
btrfs would need to be the default at all. Assuming the above 3
points improve, we don't foresee Server switching away from XFS
anytime soon. Cloud/Atomic get no major benefits from using it
(CoreOS recently moved away from btrfs). Workstation is the most
likely target but even there it is unclear how much of a benefit it
would bring.
With all that being said, the choice of filesystem is ultimately up to
the Working Groups and end users. Our input is just one piece of the
puzzle. We likely don't have much else to say on this topic, but
please keep the above points in mind in your further discussions.
josh (for the Fedora kernel team)
[1]https://lists.fedoraproject.org/pipermail/desktop/2014-March/009411.html
[2]https://lists.fedoraproject.org/pipermail/devel/2014-February/196006.html
(F21)
[3]https://lists.fedoraproject.org/pipermail/devel/2014-October/203058.html
(F22)
1:53 p.m.
On Tue, 2015-06-23 at 19:07 -0600, Stephen John Smoogen wrote:
My apologies.. my tone was not helpful. You are correct that asking
here is where to start. I think the groups who would be able to help
answer would be
1. Kernel team
2. QA team
3. Anaconda team
4. Workstation/Server/Cloud or just one if it were to be only on one
product.
We're unlikely to move forward with btrfs for Workstation until the
kernel team changes its recommendation.
3:19 p.m.
On Tue, Jun 23, 2015 at 11:41 AM, Josh Boyer <jwboyer(a)fedoraproject.org> wrote:
On Tue, Jun 23, 2015 at 1:30 PM, Andre Robatino
<robatino(a)fedoraproject.org> wrote:
> Neal Gompa <ngompa13 <at> gmail.com> writes:
>
>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
> the default in Fedora 23. At this point, I'm personally convinced that it is
> certainly ready and doable for F23.
>>
>> Perhaps other guys with more experience on this stuff could chime in with
> feedback/information/etc, but it feels like we should start the process to
> get everything ready for Btrfs being default in Fedora 23.
>
> I asked about this recently on #fedora-devel (I was the one who asked
> originally on this list) and was told there are no plans to make it the
> default yet. It's amazing that it was originally planned to be the default
> on F16 (see https://fedoraproject.org/wiki/Btrfs ). But I don't want to see
Someone created a wiki page proposing that. It was never actually
planned to be the default.
It was a feature approved by FESCo to make it the default for Fedora
16 instead of ext4.
http://meetbot.fedoraproject.org/fedora-meeting/2011-06-08/fesco.2011-06-...
But this came with some criteria to be met before freeze, namely
"btrfsck", which were not met and two months later Josef said it would
not be the default. Since he subsequently left Red Hat, only Eric
Sandeen has much Btrfs knowledge, but he works mainly on the RHEL
kernel and doesn't have time to help maintain Btrfs stuff for the very
new kernels Fedora uses beyond what upstream does.
And for that matter, no one upstream intends for serious regressions
to happen in Btrfs, yet they can and do happen. So the catch-22 with
Fedora kernels being so new, is anyone using Btrfs is going to be
among the first users to experience bug fixes, feature enhancements as
well as regressions. I don't know that having an experienced Btrfs
kernel developer on the Fedora kernel team would matter that much in
preventing regressions from landing as Fedora stable kernels. Rather,
it'd probably take an increase in time to stable or increase in karma
value to delay the unknown, until better known.
openSUSE uses Btrfs by default (except for /home) but they'd also
using much older kernels with cherry picked backported bug fixes. Even
if Fedora had a Btrfs dev I don't foresee Fedora running 3-4 major
versions of the kernel behind, just to make Btrfs the default.
--
Chris Murphy
3:42 p.m.
On Tue, Jun 23, 2015 at 2:15 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
Certainly, but with none of the features in Btrfs actually emitting
scary
"experimental" warnings anymore, and even all features working in btrfs RAID
5/6 now, I think we should really start pushing it to more people.
The multiple device stuff is no where near as feature complete in
failure contexts as mdadm or even lvm raid. There's no notification of
device failures that appear in GNOME, for example, which is the case
for mdadm managed devices.
There's been push back on the btrfs@ list about the wholesale dropping
of experimental warnings in particular with multiple device cases. So
just because there's no scary warning doesn't mean we know where all
the bodies are buried.
Or at
least develop some kind of test plan to prove the "worthiness" of using it
as default. We must have something, ne?
Well the plan right now is deference to Josef Bacik. When he says it's
ready then I think the change can happen. But there are other factors
than this, and I think it's appropriate to have more clear criteria
than just what Josef says, that incorporates other concerns.
For example: Grubby doesn't grok Btrfs subvolumes, so /boot can't be a
Btrfs subvolume. So right now the installer proscribes it and uses
ext4 for /boot similar to encrypted root and LVM layouts. However, if
grubby couldn't boot from ext4 or XFS for some reason, it would be
considered a release blocking bug. Yet this bug [1] is routinely voted
as being release blocking, but then the grubby maintainer successfully
argues to make it not release blocking because after all Btrfs is not
the default file system so who cares that it doesn't work (basically).
So some features/bugs simply aren't going to get fixed until there's
the proper incentive, obviously.
--
Chris Murphy
3:49 p.m.
On Wed, Jun 24, 2015 at 2:42 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
Yet this bug [1] is routinely voted
[1] https://bugzilla.redhat.com/show_bug.cgi?id=864198 Not that
anyone should go try to make sense out of a three year old bug with
over 100 comments... but the gist is "nah, we don't want to fix it
now, therefore the release criteria don't matter".
---
Chris Murphy
2:29 p.m.
On Wed, 2015-06-24 at 14:49 -0600, Chris Murphy wrote:
On Wed, Jun 24, 2015 at 2:42 PM, Chris Murphy <
lists(a)colorremedies.com> wrote:
> Yet this bug [1] is routinely voted
[1] https://bugzilla.redhat.com/show_bug.cgi?id=864198 Not that
anyone should go try to make sense out of a three year old bug with
over 100 comments... but the gist is "nah, we don't want to fix it
now, therefore the release criteria don't matter".
That is not an accurate summary. For F20 it was rejected as a Beta
blocker and accepted as a Final blocker. It was addressed by preventing
the installer from allowing /boot to be on a btrfs subvolume. For F21
anaconda actually allowed /boot on btrfs subvol; this wasn't
intentional but an oversight, but no-one proposed it as a blocker for
any 21 milestone and it slipped through. For F22 we handled it in the
same way as F20: it was accepted as a blocker and considered addressed
by preventing the installer from allowing /boot on btrfs.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
2:40 p.m.
On Wed, Jun 24, 2015 at 4:19 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
On Tue, Jun 23, 2015 at 11:41 AM, Josh Boyer
<jwboyer(a)fedoraproject.org> wrote:
> On Tue, Jun 23, 2015 at 1:30 PM, Andre Robatino
> <robatino(a)fedoraproject.org> wrote:
>> Neal Gompa <ngompa13 <at> gmail.com> writes:
>>
>>> As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs
becoming
>> the default in Fedora 23. At this point, I'm personally convinced that it is
>> certainly ready and doable for F23.
>>>
>>> Perhaps other guys with more experience on this stuff could chime in with
>> feedback/information/etc, but it feels like we should start the process to
>> get everything ready for Btrfs being default in Fedora 23.
>>
>> I asked about this recently on #fedora-devel (I was the one who asked
>> originally on this list) and was told there are no plans to make it the
>> default yet. It's amazing that it was originally planned to be the default
>> on F16 (see https://fedoraproject.org/wiki/Btrfs ). But I don't want to see
>
> Someone created a wiki page proposing that. It was never actually
> planned to be the default.
It was a feature approved by FESCo to make it the default for Fedora
16 instead of ext4.
http://meetbot.fedoraproject.org/fedora-meeting/2011-06-08/fesco.2011-06-...
I stand corrected. That was during the timeframe where I had briefly
left Fedora development so I clearly missed this.
josh
7:06 p.m.
On Thu, Jun 25, 2015 at 1:29 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Wed, 2015-06-24 at 14:49 -0600, Chris Murphy wrote:
> On Wed, Jun 24, 2015 at 2:42 PM, Chris Murphy <
> lists(a)colorremedies.com> wrote:
> > Yet this bug [1] is routinely voted
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=864198 Not that
> anyone should go try to make sense out of a three year old bug with
> over 100 comments... but the gist is "nah, we don't want to fix it
> now, therefore the release criteria don't matter".
That is not an accurate summary. For F20 it was rejected as a Beta
blocker and accepted as a Final blocker. It was addressed by preventing
the installer from allowing /boot to be on a btrfs subvolume.
Preventing the conditions that result in boot failure is not the same
thing as fixing the underlying problem with /boot on Btrfs being
unsupported by grubby.
Such a work around would never be considered acceptable for ext3, ext4
or XFS /boot volumes. We'd block on that. And since something like
Fedora 18/19 we supposedly agreed Btrfs should have parity with other
fs's with respect to release criteria, but plainly that's not the
case.
What really irritates me about this bug more than any in recent memory
is we had a contributor working to patch grubby to fix this problem.
The patches were tested by you and by me and they worked. Yet for f'n
9 months pjones didn't have the courtesy to bring his (eventual)
criticisms to gczarcinski. Not until at least half a dozen people had
to go through this goddamn bug, yet again, for Fedora 22 blocker
review, make it a blocker, do we get an offline relay from pjones that
the patches were deficient and he wanted to do it differently but with
no further elaboration on what that should look like in case someone
wants to do that work. And now gczarcinsk doesn't respond to any
emails to any of his email addresses: so he's either died in the long
interim it took to lead him on only to tell him to go pound salt
months later, or he's sufficiently pissed off with the Fedora process
that he's over it.
So you're right, the summary was not completely accurate.
--
Chris Murphy
7:14 p.m.
On Thu, 2015-06-25 at 18:06 -0600, Chris Murphy wrote:
On Thu, Jun 25, 2015 at 1:29 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
> On Wed, 2015-06-24 at 14:49 -0600, Chris Murphy wrote:
> > On Wed, Jun 24, 2015 at 2:42 PM, Chris Murphy <
> > lists(a)colorremedies.com> wrote:
> > > Yet this bug [1] is routinely voted
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=864198 Not that
> > anyone should go try to make sense out of a three year old bug
> > with
> > over 100 comments... but the gist is "nah, we don't want to fix
> > it
> > now, therefore the release criteria don't matter".
>
> That is not an accurate summary. For F20 it was rejected as a Beta
> blocker and accepted as a Final blocker. It was addressed by
> preventing
> the installer from allowing /boot to be on a btrfs subvolume.
Preventing the conditions that result in boot failure is not the same
thing as fixing the underlying problem with /boot on Btrfs being
unsupported by grubby.
Indeed it isn't, but I never said it was. I said your characterization
of how the release criteria have been applied was incorrect, and I
stand by that.
And since something like
Fedora 18/19 we supposedly agreed Btrfs should have parity with other
fs's with respect to release criteria, but plainly that's not the
case.
I don't recall that, do you have any references? If anything we may
have said it should get more prominence *on the basis it would soon be
the default FS*, but that basis clearly hasn't worked out in reality.
(FWIW, I'd apply the same principles to a similar bug in any FS which
is not the default for any of our release-blocking flavors.)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:41 p.m.
On Thu, Jun 25, 2015 at 6:14 PM, Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
On Thu, 2015-06-25 at 18:06 -0600, Chris Murphy wrote:
> Preventing the conditions that result in boot failure is not the same
> thing as fixing the underlying problem with /boot on Btrfs being
> unsupported by grubby.
Indeed it isn't, but I never said it was. I said your characterization
of how the release criteria have been applied was incorrect, and I
stand by that.
The phrase "nah, we don't want to fix it now, therefore the release
criteria don't matter" is a characterization of QA's application of
release criteria. It is a paraphrased, annoyed, editorialization of
this statement:
https://bugzilla.redhat.com/show_bug.cgi?id=864198#c50
"this needs to be fixed if we want to enable installing to such a
configuration, but right now we don't."
Which I questioned in the bug and didn't get a response to. I'm
criticizing this slippery slope logical fallacy that punts a fatal
grubby bug onto another team for a work around rather than an actual
fix; and also the falsehood that we don't want to enable installing
into a configuration that was approved by FESCO six releases ago.
I don't recall that, do you have any references?
It exists, but I can't find it at the moment. However, the alternative
of the unwritten exception for Btrfs is we just wait for Btrfs by
default before requiring things that should work to work, which is
distinctly cart before the horse and risks regressions or even
possibly reversion mid-cycle.
This idea that the main hold up is Btrfs upstream and a Josef sign off
is misleading. There are other things that need work. Fedora really
doesn't have its own ducks in a row. There are still some ugly UI/UX
problems in the installer, but the installer team has found more
features to add to the world's most capable OS installer, so they
don't have time this cycle for Btrfs related improvements.
--
Chris Murphy
10:42 p.m.
On Thu, Jun 25, 2015 at 9:41 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
The phrase "nah, we don't want to fix it now, therefore the
release
criteria don't matter" is a characterization of QA's application of
release criteria.
is ^NOT a characterization
(Even after proof reading it!)
--
Chris Murphy
11:21 p.m.
On Wed, Jun 24, 2015 at 12:53 PM, Michael Catanzaro
<mcatanzaro(a)gnome.org> wrote:
We're unlikely to move forward with btrfs for Workstation until
the
kernel team changes its recommendation.
There's work to be done that's not at all contingent on the kernel
team changing its rec.
Add Btrfs support to udisks (this was opened in 2010)
https://bugs.freedesktop.org/show_bug.cgi?id=26258
Wrong Disk size with btrfs
https://bugzilla.gnome.org/show_bug.cgi?id=708786
manages Btrfs multiple device volumes incorrectly, cannot umount
(obviously the above bug is still valid)
https://bugs.freedesktop.org/show_bug.cgi?id=87277
btrfs snapshot and subvolume support
https://bugzilla.gnome.org/show_bug.cgi?id=710156
The first two act as regressions if Btrfs is made default fs. The
third could corrupt the file system (it hasn't yet for me despite my
cruelty, but no file system enjoys being yanked before unmounted). The
fourth is more of a feature request.
--
Chris Murphy
1:09 p.m.
On Tue, Jun 23, 2015 at 12:24 PM, Neal Gompa <ngompa13(a)gmail.com> wrote:
Hey all,
Over the last few months (since Fedora 22 beta's release), I've been using
Btrfs as my daily driver filesystem across a multitude of machines. After
Fedora 22 released, I tried it with RAID 5 and RAID 6 enabled on a few
machines with fantastic success (there aren't even any scary warnings about
being experimental anymore!).
Admittedly, my tests have been specific to my needs (media center storage,
workstations, laptops with SSDs, etc.), but it appears to work really well
now.
Also, with kernel 4.1 imported into rawhide, we've now got performance
improvements for large (>20TB) filesystems (though it's been plenty fast for
my 48TB array).
As I recall, Josef Bacik mentioned that he'd be pushing for Btrfs becoming
the default in Fedora 23. At this point, I'm personally convinced that it is
certainly ready and doable for F23.
Perhaps other guys with more experience on this stuff could chime in with
feedback/information/etc, but it feels like we should start the process to
get everything ready for Btrfs being default in Fedora 23.
The question now is: as a distribution, where are we on this? The tools seem
to work, the filesystem appears stable, and I've not been able to cause the
filesystem to corrupt itself with any kind of user error or cause it to keel
over. So, what's left?
Sorry I completely missed this conversation. I'm not interested in
pushing btrfs into Fedora now. There is nobody to support it if
things go wrong. If you want to use btrfs you can, or you can use
Suse. We're finding and fixing things in our internal testing at
Facebook, and the power fail testing stuff I added early this year has
given me a lot of confidence in our ability to not lose all of your
data due to some weird bug. In a few months we'll have switched over
lots of our boxes onto btrfs so that will give us a pretty good way to
keep track of stability in a production environment. After that I
imagine it'll be good to go for Fedora, but that'll be somebody else's
decision, I'm no longer super interested in driving anything in
Fedora. Thanks,
Josef
3184
days inactive
3227
days old
23 comments
11 participants
participants (11)
-
Adam Williamson -
Andre Robatino -
Chris Murphy -
Gerald B. Cox -
Ian Malone -
Josef Bacik -
Josh Boyer -
M. Edward (Ed) Borasky -
Michael Catanzaro -
Neal Gompa -
Stephen John Smoogen