Frequently Asked Questions

  1. What is bcachefs Bcachefs is an advanced new filesystem for Linux, with an emphasis on reliability and robustness and the complete set of features one would expect from a modern filesystem.

  2. How does bcachefs compare to other Linux filesystems like ext4, btrfs, xfs, and zfs? The bcachefs filesystem has various advantages over other Linux filesystems. Bcachefs is a feature complete filesystem while also containing extra features such as checksumming and multi-device functionality within a filesystem. These are both features that are absent from the ext4 and xfs filesystems. Other benefits presented by bcachefs include a focus on reliability, robustness, and performance. Bcachefs is safer to use than btrfs and is also shown to outperform zfs in terms of speed and reliability.

  3. Is bcachefs stable for production use? Yes. bcachefs has a growing user base and has been stable for quite some time. It includes extensive self-healing and repair capabilities - if something does go wrong, bcachefs is designed to detect and fix it automatically where possible.

  4. How do I install and use bcachefs on my Linux system? Instructions for installation can be found here: Getting Started

The user manual can be found here: bcachefs-principles-of-operation.pdf

  1. Does bcachefs support data deduplication and compression? Bcachefs currently does not support data deduplication however compression is supported, more information can be found here: Compression

  2. Are there any limitations or known issues with bcachefs? Information on current bugs within bcachefs and related tooling can be found here: bcachefs bugs bcachefs-tools bugs

Our roadmap/todo list can be found here: Roadmap

  1. What is the development status of bcachefs? bcachefs is mature and actively developed. It ships as a DKMS module (like ZFS) with packages available for most distributions. See Getting Started for installation instructions, and Roadmap for planned features.

  2. Can I migrate my existing filesystem to bcachefs? Yes, users can migrate their existing filesystems into a bcachefs filesystem using the 'bcachefs migrate' subcommand

  3. Are there any recommended use cases for bcachefs? Bcachefs is primarily for multi-device filesystems.

  4. How do I contribute to the bcachefs project? Information on contributions can be found here: Contributing Join the IRC channel and chat with other contributers

  5. Do I have to reformat my bcache drive to use the new bcachefs ? To use the caching device (cdev) with the new bcachefs, you will need to reformat it. In principle this should not be a problem, as they can be removed from a backing device (bdev/bcache).

If you wish to reuse the backing device (bdev/bcache), you can't - this is no longer an option.

If you wish to use bcachefs as a filesystem you will have to format the backing device (bdev/bcache) with the new filesystem.

  1. Does bcachefs still have the bcache caching functionality of block devices ? No.

  2. Where do I obtain statically linked bcachefs-tool (for use in initramfs) ? You can either compile them yourself from source, or refer to your distribution on how to obtain a statically linked set.

Statically linked programs have all the required dependencies compiled in. As such, they require no external libraries at runtime. This does however increase the size of the binary.

  1. What is liburcu ? userspace RCU (read-copy-update) library http://lttng.org/urcu

  2. I get the error "mount(2) system call failed: Required key not available." You need to unlock the filesystem before mounting. As a superuser, run (substituting your drive for /dev/sdc1): bcachefs unlock /dev/sdc1

If the error persists, it might be because you're using sudo and root's keyring is not connected to your session. To verify, run these two commands: sudo keyctl list @u sudo keyctl list @s

The first one displays the keys in root's keyring, and should mention external UUID of your bcachefs filesystem (which you can find with bcachefs show-super /dev/scd1). The second one displays your session's keyring, and should mention uid.0 (root).

If you don't see uid.0 in the output of the second command, connect root's keyring to your session: sudo keyctl link @u @s