On Tue, Jun 23, 2015 at 9:07 PM, Stephen John Smoogen <smooge@xxxxxxxxx> 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 1:15 PM, Neal Gompa <ngompa13@xxxxxxxxx> 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@xxxxxxxxx> wrote:
On 24 June 2015 at 04:28, M. Edward (Ed) Borasky <znmeb@xxxxxxxxx> wrote:
> On Tue, Jun 23, 2015 at 1:15 PM, Neal Gompa <ngompa13@xxxxxxxxx> 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 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!
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
