On Tue, Jun 23, 2015 at 9:07 PM, Stephen John Smoogen <smooge(a)gmail.com>
On 23 June 2015 at 18:40, Neal Gompa <ngompa13(a)gmail.com>
> That is precisely why I'm asking on this list. I don't know who those
> are, and this is really the best place I know of to start contact and
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
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>
On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa
> Certainly, but with none of the features in Btrfs actually emitting scary
> "experimental" warnings anymore, and even all features working in btrfs
> 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
> 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
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
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
> 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
>> "experimental" warnings anymore, and even all features working in
>> 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
>> 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
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!