Red Hat Bugzilla – Full Text Bug Listing
|Summary:||need to make sure btrfs support works properly|
|Product:||[Fedora] Fedora||Reporter:||Josef Bacik <jbacik>|
|Component:||grub2||Assignee:||Peter Jones <pjones>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||rawhide||CC:||dennis, henrik, lkundrak, mads, pjones, the.ridikulus.rat, vserbine|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-08 15:08:45 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Josef Bacik 2011-03-21 13:39:36 EDT
We need to make sure we can boot with a /boot on btrfs in all of its various incarnations. At first single disk should be just fine, but it would be good for it to eventually work with RAIDed filesystems as well.
Comment 1 Fedora Admin XMLRPC Client 2011-09-16 15:07:55 EDT
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Comment 2 Mads Kiilerich 2012-04-16 09:00:18 EDT
Be aware of upstreams 'by design' limitations: http://www.gnu.org/software/grub/manual/grub.html#Environment-block """ For safety reasons, this storage is only available when installed on a plain disk (no LVM or RAID), using a non-checksumming filesystem (no ZFS), """ Another limitation is the size of core.img with support for btrfs - it will not fit into the 63 sectors available on many already partitioned disks. "Full" support for /boot on btrfs might thus not be feasible. (It seems to me like the best solution would be if btrfs (and raid and lvm) could be designed in such a way that it was possible to mark a directory or file as special so that the file system automatically traded some of the fancy features for simplicity so it was suitable for boot loader needs.)
Comment 3 Henrik Nordström 2012-04-16 19:09:20 EDT
btrfs bave 64KB reserved for boot code in plain blocks. See bug #748071. Should be possible to set aside 1KB for environment and 63KB for core.img which should be sufficient for most if not all btrfs configurations. There also seems to be support for btrfs RAID1, RAID10 (and RAID0).
Comment 4 Mads Kiilerich 2012-04-30 18:19:28 EDT
grub2-2.0-0.24.beta4.fc17 has been pushed to f17 stable and support /boot on btrfs. Does that solve this issue?
Comment 5 Henrik Nordström 2012-04-30 19:32:58 EDT
Not sure what this issue really is about. The description is very general, probably too general. and no, grub2 do not support btrfs in all it's incarnations, But most. There seems to be support for RAID1/0/10. Have not tested fully yet. But there is no good support for subvolumes (or snapshots) that make sense in grub. This would require the ability to specify to grub which subvolume to use as it's root of the btrfs. did you mean to comment on bug #748071?
Comment 6 Mads Kiilerich 2012-05-01 05:28:00 EDT
(In reply to comment #5) > did you mean to comment on bug #748071? No; that bug seems very well-defined and track a specific issue that perhaps one day can be marked as solved. (The only way to make that happen would be if RH allocated resources for it or if you get involved upstream.) Like you I just wondered what this issue really is about.
Comment 7 Vladimir Serbinenko 2012-06-02 09:00:49 EDT
@Henrik: I've tested with subvolumes and it works with no problem. Subvolumes work mostly like directories on btrfs. So you need to access them as: (device)/subvolume/filepath
Comment 8 Vladimir Serbinenko 2012-06-02 09:13:46 EDT
I have a test suite for all filesystems in GRUB. For some of them GRUB has limitations like no hardlink support on HFS+ (not mentionining inherent FS limitations). For btrfs it tests standard FS features, zlib, lzo, raid0/raid1/raid10. What else does Fedora/RH need to be tested.
Comment 9 Peter Jones 2012-08-08 15:08:45 EDT
Josef, if there are specific issues please open a specific bug about them, but until I know otherwise I'm considering Vladimir's comments #7 and #8 to be an affirmative response that this should work.