Kent Overstreet announced Bcachefs as “the COW filesystem for Linux that won’t eat your data” in 2015. Since then the system has undergone numerous updates and patches to get to be where it is today. On the 1st of December, Overstreet published an update on the problems and improvements that are currently being worked upon in Bcachefs.
Status update on Bcachefs
After the last update, Overstreet has focussed on two major areas of improvement- atomicity of filesystem operations and non-persistence of allocation information (per bucket sector counts).
The filesystem operations that had anything to do with i_nlink were not atomic. On startup, the system would have to scan and recalculate i_nlink and also delete no longer referenced inodes. Also, because of non-persistence of allocation information, on startup, the system would have to recalculate all the accounting disk space.
The team has now been able to get everything to be fully atomic except for fallocate/fcollapse/etc. After an unclean shutdown, the only thing to be done is scan the inodes btree for inodes that have been deleted. Erasure coding is about 80% done now in Bcachefs.
Overstreet is now focussed on persistent allocation information. This will then allow him to focus on ‘reflink’ which in turn will be useful to the company that’s funding bcachefs development. This is because the reflinked extent refcounts will be much too big to keep in memory and hence will l have to be kept in a btree and updated whenever doing extent updates. The infrastructure needed to make that happen also depends on making disk space accounting persistent.
After all of these updates, he claims bcachefs will have fast mounts (including after unclean shutdown). He is also working on some improvements to disk space accounting for multi-device filesystems which will lead up to fast mounts after clean Shutdowns. To know if a user can safely mount in degraded mode, they will have to store a list of all the combinations of disks that have data replicated across them (or are in an erasure coded stripe) – without any kind of fixed layout, like regular RAID does.
Why should you choose Bcachefs?
Overstreet announced that Bcachefs is stable, fast, and has a small and clean code-base, along with the necessary features to be a modern Linux file-system. It has a long list of features, completed or in progress:
- Copy on write (COW) – like zfs or btrfs
- Full data and metadata checksumming
- Caching
- Compression
- Encryption
- Snapshots
- Scalable
- Bcachefs prioritizes robustness and reliability
According to Kent, Bcachefs ensures that customers won’t lose their data. The Bcachefs is an extension of bcache where the bcache was designed as a caching layer to improve block I/O performance. It uses a solid-state drive as a cache for a (slower, larger) underlying storage device. Mainline bcache is not a typical filesystem but looks like a special kind of block device. It handles the movement of blocks of data between fast and slow storage, ensuring that the most frequently used data is kept on the faster device. bcache manages data in a way that yields high performance while ensuring that no data is ever lost, even when an unclean shutdown takes place.
You can head over to LKML.org for more information on this announcement.
Read Next
Google Project Zero discovers a cache invalidation bug in Linux memory management, Ubuntu and Debian remain vulnerable
Linux 4.20 kernel slower than its previous stable releases, Spectre flaw to be blamed, according to Phoronix
The Ceph Foundation has been launched by the Linux Foundation to support the open source storage project