Kent Overstreet, the author of the SSD block device caching system BCache, summarized the progress of the Bcachefs file system in the main Linux kernel during his talk at the LSFMM 2023 (Linux Storage, Filesystem, Memory Management & BPF Summit). He discussed plans for further development of this file system. In May, an updated set of patches implementing Bcachefs was proposed for review and inclusion in the main Linux kernel. Bcachefs has been in development for about 10 years. The readiness for reviewing the Bcachefs implementation for inclusion in the kernel was announced back in late 2020, and the current patch set addresses the comments and shortcomings identified in previous reviews.
The goal of developing Bcachefs is to achieve XFS-level performance, reliability, and scalability while providing additional capabilities typical of Btrfs and ZFS, such as the ability to include multiple devices in a volume, layered storage layouts, replication (RAID 1/10), caching, transparent data compression (LZ4, gzip, and ZSTD modes), state snapshots, integrity verification via checksums, the possibility of storing Reed-Solomon error correction codes (RAID 5/6), and information storage in encrypted form (using ChaCha20 and Poly1305). In terms of performance, Bcachefs outperforms Btrfs and other Copy-on-Write-based file systems, showing speeds comparable to Ext4 and XFS.
Recent advancements in the development of Bcachefs highlight the stabilization of the implementation of writable snapshots. Compared to Btrfs, snapshots in Bcachefs now scale significantly better and are free from the issues typical of Btrfs. In practice, the functionality of snapshots has been tested in organizing MySQL backups. Additionally, substantial work has been done in Bcachefs to improve scalability—the file system has performed well during testing in storage systems sized at 100 TB, and the implementation of Bcachefs in a 1 PB storage system is expected soon. A new nocow mode has been added to disable the copy-on-write mechanism (nocow). Over the summer, there are plans to stabilize the implementation of error correction codes and RAIDZ, as well as address high memory consumption issues during filesystem recovery and checks by the fsck utility.
Future plans include a desire to use the Rust programming language in the development of Bcachefs. The author of Bcachefs believes in programming rather than debugging, and now finds it crazy to write code in C when a better option is available. Rust is already utilized in Bcachefs for implementing several utilities running in user space. Furthermore, there is an idea to gradually rewrite Bcachefs entirely in Rust, as using this language significantly saves debugging time.
Regarding the promotion of Bcachefs to the mainline of the Linux kernel, the acceptance process may be prolonged due to the considerable size of the changes (2,500 patches and about 90,000 lines of code), which are difficult to review. To expedite the review process, some developers have suggested breaking the series of patches into smaller, logically separated parts. During discussions, some participants also noted the concern of the project being developed by a single developer and the risk that the code could be left without support if something were to happen to the developer (two Red Hat employees have shown interest in the project, but their work is currently limited to bug fixes).
Bcachefs is being developed using technologies already proven in the creation of the Bcache block device, designed to cache access to slow hard drives on fast SSDs (included in the kernel starting from release 3.10). Bcachefs employs a Copy-on-Write (COW) mechanism, where changes do not overwrite existing data — the new state is written to a new location, after which the pointer to the current state is changed.
A distinctive feature of Bcachefs is the support for layered storage device connections, where the storage is composed of several layers — the bottom layer connects the fastest drives (SSDs), which are used to cache frequently accessed data, while the upper layer consists of larger and cheaper disks that provide storage for less frequently accessed data. Writeback caching mode can be applied between the layers. Drives can be dynamically added and detached from the partition without stopping the use of the file system (data migrates automatically).
Source: opennet.ru
