Bug 969867
Summary: | btrfs-progs does not support raid5 or raid6 - Fedora 18 and Fedora 19 | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Gerald Cox <gbcox> |
Component: | btrfs-progs | Assignee: | Josef Bacik <josef> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 19 | CC: | esandeen, josef, mmahut |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc19 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-09-30 00:38:57 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Gerald Cox
2013-06-02 19:50:34 UTC
"btrfs-progs should be kept current to allow usage of that function." s/usage/testing/ :) btrfs-progs hasn't had a point release upstream for ages (years?) so we can only do a best-effort approach, pushing random upstream git snapshots into fedora. Since upstream btrfs-progs never stabilizes, it's hard to know when an appropriate time to update might be, or whether it ever makes sense to push updates to older fedoras. (when the new raid code landed it was very new & untested; how much risk we want to foist onto Fedora users is an open question). FWIW, I updated btrfs-progs in rawhide in the beginning of may, and that probably has the raid code in it. Yes, the version in rawhide has the code to allow use of raid5/6. My point was that the raid 5/6 support is included in the 3.9 kernel - Fedora 18 is now at 3.9.4 so everyone is being exposed to that code. btrfs-progs allows people to use it if they choose. I think it makes sense to push the updates to support the functionality which is included in the current kernel, updating btrfs-progs isn't going to affect anyone who isn't using btrfs. My personal POV here (and Zach or Josef can chime in if they want) is that pushing a bleeding edge git snapshot to F18 so that a few people can experiment with new raid code raises unknown risks for F18 users who are happily doing simpler things with their btrfs filesystems, possibly using it for something besides just testing. If upstream had any sense of stable release points it'd be much less of a worry, but I've given up pretty much all hope of that. So dumping a new git snapshot on older stable releases raises concerns for me. Put another way: If you want to play with bleeding edge btrfs features, rawhide is probably the better place to do it, IMHO. I'm just trying to be a bit cautious here... Eric, I respect your opinion and very much appreciate the fact that it is at least available in rawhide to download. Thanks for that. However, I respectfully disagree with your opinion. Here is my opinion... BTRFS is by definition experimental. Anyone using it receives the warning message that it is in fact experimental. The wiki plainly says it is under heavy development. While you point out that the new code may introduce risk, you aren't giving adequate weight to the fact that it is also fixing issues and allowing use of features which are now in the F18 kernel. Let me repeat, because I don't think you are getting that point. The Fedora 18 kernel: kernel-3.9.4-200.fc18.x86_64 has the support for raid 5/6. It is already there...but you need the associated btrfs-progs to be able to use it. My point is that if Fedora is shipping the kernel in the Fedora 18 repository, NOT rawhide then it is reasonable to believe that one should be able to use those features and not have to search for them in rawhide. The whole point of BTRFS at this point is to test the features. There is no BTRFS production at this point... it is all experimental and under heavy development. Your comment about "dumping a new git snapshot on older stable releases" I don't think is correct. First, I'm not asking you to add it to F17 - but since F18 is shipping the kernel which supports the features, it should have the code. Also, again, by definition, btrfs-progs isn't stable, it is experimental, under heavy development - and while you think the new code may cause issues, it is just as likely at this point to be solving serious issues. Thanks for repeating your point, but I do get it. I understand that F18 now has the highly experimental and unstable raid code. My point is that F18 might not be the right place to test bleeding edge btrfs. But whatever, josef is the maintainer, I'll defer to him. -Eric Thanks Eric for your quick responses, and again I do very much appreciate the fact that the code is available in rawhide. As a side note, am very pleased with how simple it was to setup the raid6 array. Running it on 6 3TB sata drives and so far no errors and been amazed at the performance. Running /boot /swap /tmp and /home on EXT4 - I'm brave, but not that brave... LOL... btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc19 A new git snapshot of btrfs-progs has been pushed to F19 testing. If possible, please re-test these bugs & feel free to close or comment as appropriate. Thanks, -Eric Package btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-17126/btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc19 then log in and leave karma (feedback). btrfs-progs-0.20.rc1.20130917git194aa4a-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report. |