The genkernel initramfs script does not contain any support to register bcache devices. In order to put root or /usr on a bcache, one needs to echo the device nodes containing the backing and cache block devices into /sys/fs/bcache/register before /dev/bcache* will appear. Udev rules do this, but mdev in genkernel’s initramfs appears not to, and the initramfs /init doesn’t do it either. Note that this is NOT the same as bug 522688, despite having an almost identical title. That ticket is about enabling bcache support in the kernel .config, which can easily enough be done by hand through menuconfig. This ticket is about enabling support in the initramfs, which AFAICT there is no way to do right now (I don’t see any support for custom commands which get called during the script, for example).
Patches or pusedocode welcome. Please base your work on the 'master' branch of genkernel, as the v3.5 series have moved on a lot since v3.4.
Created attachment 558380 [details, diff] 0001-linuxrc-Add-support-for-bcache.patch I've created and tested the attached patch. The upside is that adding 'dobcache' to the kernel command line allows root to be a bcache device. In my case, the backend device was even a software RAID 1 block device. However there are two downsides as far as I can tell: - It may not attempt to register all potential bcache block devices. Ideally a userspace utility in the initrd would take care of that (e.g. a hypothetical "bcache --scan --register") - Since it attempts to register all devices matching the shell glob, it "spams" the kernel log buffer with "bcache: register_bcache() error /dev/sda2: Not a bcache superblock" messages
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=3764e9c41cf80d2ba3a391bb7ea014241ab34170 commit 3764e9c41cf80d2ba3a391bb7ea014241ab34170 Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-07-14 10:48:01 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-07-14 11:58:18 +0000 Add bcache support Kernel command-line argument only, adds "dobcache". Bug: https://bugs.gentoo.org/605094 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> arch/alpha/modules_load | 2 +- arch/arm/modules_load | 2 +- arch/ia64/modules_load | 2 +- arch/mips/modules_load | 2 +- arch/parisc/modules_load | 2 +- arch/parisc64/modules_load | 2 +- arch/ppc/modules_load | 2 +- arch/ppc64/modules_load | 2 +- arch/ppc64le/modules_load | 2 +- arch/s390/modules_load | 2 +- arch/sparc/modules_load | 2 +- arch/sparc64/modules_load | 2 +- arch/um/modules_load | 2 +- arch/x86/modules_load | 2 +- arch/x86_64/modules_load | 2 +- defaults/initrd.defaults | 4 ++-- defaults/initrd.scripts | 21 +++++++++++++++++++++ defaults/linuxrc | 3 +++ defaults/modules_load | 2 +- doc/genkernel.8.txt | 4 ++++ gen_cmdline.sh | 6 ++++++ gen_configkernel.sh | 9 +++++++++ gen_determineargs.sh | 1 + genkernel | 1 + genkernel.conf | 3 +++ 25 files changed, 66 insertions(+), 18 deletions(-)
Glad to see some progress is happening, thanks! However, from looking at the Git commit, would it not make more sense to do bcache scanning *before* btrfs and ZFS scanning? My intended use case was to put a btrfs filesystem on top of bcache, and I can’t see it being likely that anyone would put a bcache on top of btrfs (indeed the way scanning is implemented right now, I don’t think that would even work since it only scans /dev/ nodes). Or do I totally misunderstand how start_volumes works?
(In reply to Christopher Head from comment #4) > Glad to see some progress is happening, thanks! However, from looking at the > Git commit, would it not make more sense to do bcache scanning *before* > btrfs and ZFS scanning? My intended use case was to put a btrfs filesystem > on top of bcache, and I can’t see it being likely that anyone would put a > bcache on top of btrfs (indeed the way scanning is implemented right now, I > don’t think that would even work since it only scans /dev/ nodes). > > Or do I totally misunderstand how start_volumes works? Forgive me, I am not a bcache user. This is what people told me. You mean moving the scan upward, before LVM check (https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/initrd.scripts?id=3764e9c41cf80d2ba3a391bb7ea014241ab34170#n1231)?
(In reply to Thomas Deutschmann from comment #5) > Forgive me, I am not a bcache user. This is what people told me. > > You mean moving the scan upward, before LVM check > (https://gitweb.gentoo.org/proj/genkernel.git/tree/defaults/initrd. > scripts?id=3764e9c41cf80d2ba3a391bb7ea014241ab34170#n1231)? I’m not sure whether it should be before or after LVM. Honestly I could see arguments for both. If I have, say, three SSDs and three hard drives, I could: * combine the three SSDs into one big LV with LVM, and the three HDs into one big LV with LVM, and then put bcache on top of the two LVs, or * combine HD1 + SSD1 into bcache1, combine HD2 + SSD2 into bcache2, combine HD3 + SSD3 into bcache3, and then use LVM to build RAID over bcache1+bcache2+bcache3. I have no idea which way people would tend to go here. However, btrfs is a filesystem. Filesystem scanning really makes sense to do after all block devices are set up (and bcache is a block-level thing—it makes a block device out of two other block devices); I think hardly anyone would want this the opposite way. The most flexible way to handle things is probably to iterate until the system reaches a fixed point, but that’s clearly far too complex to handle in a small patch (and maybe not really even practical to do at all in an initramfs).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/genkernel.git/commit/?id=6a3eedab7ad0e26ff13edee1881bd5498075c36a commit 6a3eedab7ad0e26ff13edee1881bd5498075c36a Author: Thomas Deutschmann <whissi@gentoo.org> AuthorDate: 2019-07-14 19:35:06 +0000 Commit: Thomas Deutschmann <whissi@gentoo.org> CommitDate: 2019-07-14 19:35:06 +0000 initrd.scripts: start_volumes(): Move bcache initialation below LVM but before BTRFS/ZFS Bug: https://bugs.gentoo.org/605094 Signed-off-by: Thomas Deutschmann <whissi@gentoo.org> defaults/initrd.scripts | 42 +++++++++++++++++++++--------------------- 1 file changed, 21 insertions(+), 21 deletions(-)
OK, let's see how this will work. I'll tag and add first beta later this night.
Well, it’s in stable now, and it works perfectly, thanks!
