For F19, dracut will most likely default to the "host only" mode, where the initrd is adjusted to the actual storage configuration of the local system, rather than strictly universal. In the best case this might have the effect that no initrd is required and generated at all anymore (that is if you have common hardware and no fancy storage setup). Not having an initrd makes things a lot faster at boot, actually, so this is a really good thing. Now, with this dracut change on a typical AHCI laptop with plain ext4 you are in the lucky position that the initrd is suppressed entirely. However, as soon as you use btrfs for the root file system you are out of luck: since btrfs is currently a module, we still need to build an initrd for it. So, I was wondering if it might be time to compile btrfs into the kernel for F19? As it looks now btrfs is likely to become the default fs for Fedora anyway soonishly, so maybe it's time by now to just compile it in rather then load as a module? For my own setup this would then allow me to boot without initrd on my AHCI+btrfs setup, and I'd be a happy man. And sooner or later I figure this could become the default setup anyway, and hence would for most folks "default to fast".
I would welcome this very much, as it brings btrfs to the same level as ext4.
(In reply to comment #1) > I would welcome this very much, as it brings btrfs to the same level as ext4. Except btrfs isn't at the same level as ext4. There are still a number of outstanding issues that are being worked. There's a reason the btrfs maintainers haven't proposed it as the default FS in Fedora yet. Compiling it into the kernel just adds another 1.2MB of space to the vmlinux that everyone is going to have loaded. CC'ing Eric and Zac to see what their thoughts are.
TBH, most users only use one filesystem on a system in any case. So building in brtfs, xfs, ext4 is going to waste space for *someone* regardless of the maturity of any of the code. So speaking for myself, I don't care so much about the space ;) The downside from my perspective is that it's more difficult for users to do a quick test of btrfs fixes by loading a new module. Not that we do it all that often, but sometimes it's nice... On the other hand, if btrfs filesystems are't present on the system, having it as a module doesn't matter a bit to dracut, right? And that's probably quite common today? -Eric
I guess I don't really have a strong opinion on this. I like the idea of saving boot time if you're using btrfs. I like the idea of saving space if you're not. I looked and btrfs.ko only does boring house keeping on module init, so there's that. (sysfs and fs registration, slab cache init, initializing some static tables.) > As it looks now btrfs is likely to become the default fs for Fedora anyway soonishly, I don't think btrfs is likely to become the default fs any time soon.
Can we please still have that? :) We need to start somewhere to bring it to the same level of integration as ext, and it's too handy to boot boxes with the kernel only, and not needing an initrd.
We are not asking to make it the default, but just to get it built into the kernel. Maybe just consider this the first step towards making it the default one day. It would make it much easier for us to test things automatically with it. We have a certain level of btrfs integration in systemd (for example, automatic assembly of the RAID stuff, or the btrfs defrag stuff in readahead, and suchlike), and I'd like to add more, but I am having a hard time because it's so fragile because it depends on the initrd. I mean, I can totally understand that I am personally probably not the only user of Fedora to consider on this, but I'd really appreciate this, to make my work easier, and the work of a few others doing low-level integration stuff. So, please, please, which a cherry on top! ;-)
given btrfs is nowhere near being ready for default fs yet, this is just a waste of over 1MB of memory for every user. I'd sooner do the built-in thing for XFS tbh, but that has the same issue. We're increasing our memory footprint for a niche case.