bcachefs eviction

[fbeth]

Hi,

Since the recent eviction of bcachefs from the kernel I have a few questions. I'm not the most technical user and I don't fully understand how much I'll be affected by this decision.

I currently compile myself the kernel provided by the package gentoo-sources and my home partition is a bcachefs volume. What I understand is that bcachefs will be distributed like nvidia's drivers as a dynamic kernel module, this sound like a complication and I was wondering if distributions like Gentoo could choose to still include bcachefs in their kernels just like before. If not, will I be able to patch my kernel to include bcachefs like on 6.16 ?

[NeddySeagoon]

fbeth,

As bcachefs will become a kernel module, you may not notice.
It should be loaded when it's requied to mount /home.
It would be more of a problem were it needed to mount root, as the modwle would need to be in your inird and loaded there befbre root could be mounted.

As a module, bcachefs will have all the problems that the nvidia kernel module has.
You may be waiting for updates to be able to build it against a new kernel.

If you need to ask, you cannot patch your kenel to make it a built in.
You would need the updates that I have hinted at above and some new code to drive the kernel configuration tools, then possibly some changes to the bcachefs code that interfaces to the kernel to account for the module vs built in dependencies.

[DeIM]

Pity. I use bcachefs in production on several non-critical devices (PC/laptops - as root somewhere), where I tried to avoid initramfs, building all needed inside kernel.
I'm familiar with /etc/portage/patches so if it would be possible to somehow time after time build this way it could be relatively fine.
It would be even better to somehow get support via experimental flag in sys-kernel/gentoo-sources.

I really pray for return to kernel soon or later.

[fbeth]

Thanks NeddySeagoon for your answer, I guess I'll just roll with the troubles from now.

I really pray for return to kernel soon or later.

I can't agree more with you. I'm optimistic, I think it's a really great filesystem. I'm no kernel maintainer, but I understand why would they be fed up by koverstreet's acts. When the project will be mature enough I don't see why I wouldn't be part of the kernel again.

[fpemud]

@fbeth, @DeIM are you using bcachefs in an SSD+HDD setup? What's your experience been like?

I'm especially curious if hot data is effectively stored on the SSD (forground device).

I'm hoping it can be better than bcache+btrfs, for example have a higher cache hit ratio.

[Ionen]

Edit: recommend to ignore this post, old .deb aren't archived and the situation + options usage changed so it's unlikely this ebuild will stay usable/right, should probably let bcachefs upstream sort things out for a while before anyone tries to write a proper ebuild

I don't intend to push this nor maintain it nor offer real support, but if anyone interested I randomly made an ebuild for the out-of-tree version. Haven't actually tried the module though, only checked that it builds against gentoo-kernel-bin-6.16.8, so no idea if it works. Use at your own risks esp. if for a rootfs+initramfs mount.

Intended for version 1.31.2, ebuild may need updates for any other version but I won't be looking at that.

bcachefs-1.31.2.ebuild:

Code: Select all

# Copyright 2025 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI=8

MODULES_INITRAMFS_IUSE=+initramfs
inherit linux-mod-r1 unpacker

DESCRIPTION="The COW filesystem for Linux that won't eat your data"
HOMEPAGE="https://bcachefs.org/"
# no proper source tarball yet(?), grab from the .deb (arch does not matter)
SRC_URI="https://apt.bcachefs.org/unstable/pool/main/b/bcachefs-tools/bcachefs-kernel-dkms_${PV}_amd64.deb"
S=${WORKDIR}/usr/src/${P}

LICENSE="GPL-2 BSD LGPL-2.1+"
SLOT="0"
KEYWORDS="~amd64"

CONFIG_CHECK="BCACHEFS_FS"
ERROR_BCACHEFS_FS="CONFIG_BCACHEFS_FS: is not set but is (still) needed to build the
	out-of-tree version of ${PN} as it re-uses kernel config options
	and is not currently fully independent (this module will be
	prioritized over the kernel's if both exists as long as not builtin)"

DOCS=( ../../share/doc/bcachefs-kernel-dkms/changelog )

src_prepare() {
	default

	sed -i "s:/usr/src/.*:${S}/src/fs/bcachefs:" src/fs/bcachefs/trace.h || die

	gzip -d ../../share/doc/bcachefs-kernel-dkms/changelog.gz || die
}

src_compile() {
	local modlist=( bcachefs=::src/fs/bcachefs )
	local modargs=(
		KDIR="${KV_OUT_DIR}"
		CONFIG_MEAN_AND_VARIANCE_UNIT_TEST=
	)

	linux-mod-r1_src_compile
}

wrt the ERROR_ message, afaik the module isn't actually leaving the kernel yet but it's going to become outdated most likely and an ebuild lets you get a more recent version.
Edit/Update: well, it did leave after all -- bchafefs upstream did update their Makefile but it doesn't handle other options right now, and the things it need to be enabled in the kernel are a pain to select for a non-generic kernel given lot of options do not have directly select'able menu entries -- e.g. need to enable btrfs to enable them among other things

Could probably still use some improvements, like error out if BCACHEFS_FS is set as builtin rather than module, may or may not need more things in CONFIG_CHECK too, albeit the in-kernel Kconfig BCACHEFS_FS likely selects most things needed. With gentoo-kernel-bin did not have to worry too much given it enables about everything.

To avoid collisions, the module will be installed to /lib/modules/*/extra/ rather than kernel/fs/bcachefs/ -- the "extra" dir is special and should take priority for which of the two bcachefs.ko to load. If using a initramfs needed for a rootfs, may want to double-check that it did get included or else it will load the other one (it should with dracut because of the generated config file the eclass installs, but I haven't actually tried USE=initramfs).

[fbeth]

@fbeth, @DeIM are you using bcachefs in an SSD+HDD setup? What's your experience been like?

I'm especially curious if hot data is effectively stored on the SSD (forground device).

I'm hoping it can be better than bcache+btrfs, for example have a higher cache hit ratio.

Yes I'm using this setup. I have an NVMe drive with my ext4 root partition on it and half the drive for my bcachefs foreground, the background is the whole HDD. It's been a year and so far I'm really happy with it. I never took the time to do a real benchmark, but the thing I noticed the most was when I was playing factorio, the game took very long to load on my previous install (Games on HDD) and since I switched to bcachefs it's way faster. Something like 15 seconds now while before it was almost a minute. I really like the idea of the computer doing all the work of selecting hot data for me. Stability wise I never hit any major issue or corruption. The only problem I had is the partition not always auto-mounting. It happens like 10% of the time and a simple mount -a solves it. I opened an issue on github and apparently it has something to do with openrc. I understood that they rely on a systemd signal which doesn't exist in openrc and the partition is mounted at a more random time, before all disks are up. They are currently working on the userspace program to handle this instead of relying on the init.

[DeIM]

Trying another approach - bcachefs git master repo, with gentoo patches.
Don't know if it worth trying but bcachefs repo is 6.17.0, patches to .6 are not applied, seem genpatches also.
Just curious if it could be done better.

Code: Select all

# Copyright 1999-2025 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2

EAPI="8"
ETYPE="sources"
K_WANT_GENPATCHES="base extras experimental"
K_GENPATCHES_VER="9"

inherit check-reqs kernel-2 git-r3
detect_version
detect_arch

DESCRIPTION="Full sources including the Gentoo patchset for the ${KV_MAJOR}.${KV_MINOR} kernel tree"
HOMEPAGE="https://dev.gentoo.org/~alicef/genpatches"
EGIT_REPO_URI="git://evilpiepirate.org/bcachefs.git"
EGIT_CLONE_TYPE="shallow"
SRC_URI="${GENPATCHES_URI} ${ARCH_URI}"
KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~loong ~m68k ~mips ~ppc ~ppc64 ~riscv ~s390 ~sparc ~x86"
IUSE="experimental"
S="${WORKDIR}/${P}"

pkg_pretend() {
        CHECKREQS_DISK_BUILD="4G"
        check-reqs_pkg_pretend
}

src_prepare() {
        kernel-2_src_prepare
        rm "${S}/tools/testing/selftests/tc-testing/action-ebpf"
}

pkg_postinst() {
        kernel-2_pkg_postinst
        einfo "For more info on this patchset, and how to report problems, see:"
        einfo "${HOMEPAGE}"
}

pkg_postrm() {
        kernel-2_pkg_postrm
}