On Tue, 29.01.13 14:17, Adam Williamson (awilliam@xxxxxxxxxx) wrote: > On Tue, 2013-01-29 at 14:06 -0700, Chris Murphy wrote: > > Am 29.01.2013 16:55, schrieb Bryn M. Reeves: > > > Again, unless you have very different storage controllers this will not break. > > > > > > I really don't want or need every FC HBA kernel module, firmware bin file or other junk in my laptop initramfs > > > "just in case" I happen to swap the disk to a laptop with built-in fibre-channel :-) > > > The proposal not seem to be a significant performance enhancer. > > <snip> > > This is just what I was going to ask for: numbers. I don't see how we > can make a reasoned decision on a feature whose primary stated basis is > 'performance', when said feature provides zero data on the claimed > performance improvement. > > Per Lennart's mail it seems Chris' attempt is flawed, but at least he > made an attempt. Perhaps the feature proposers could take the time to > provide some numbers, taking Lennart's feedback into account? The onus > would appear to be on them. Full disclosure: I am actually really hoping for Harald's feature to include something that's not on the feature page right now: and that is the strongest form of host-only initrd support -- when the root disk is on a file system and storage that is accessible with compiled-in drivers, then dracut would skip generation of an initrd entirely. I have been running Linux regularly with and without initrd in the F15-F17 cycles (simply since we needed to support both cases with systemd). Then, booting without initrd usually cut off about 20% of the boot time. (I can't give you any up-to-date numbers for that however, since after I reinstalled my machine in the F18 development cycle I chose btrfs as root fs. btrfs is currently compiled as module, which means I cannot boot without initrd. I have now filed this bug so that I can start testing initrd-less boots again: https://bugzilla.redhat.com/show_bug.cgi?id=905611 ) Hey, Harald, any chance we can get the non-initrd-where-not-necessary trick, too? That would be too cool ;-) Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
