Puzzlefs is a container file system designed by Cisco.
Cisco recently announced via the Linux Kernel mailing list a proposal for a new file system which is called "PuzzleFS" and which is proposed to be implemented as a module for the Linux kernel.
puzzleFS, is a file system written in Rust, designed by cisco to house insulated containers and continues the development of the ideas proposed in the AtomfsFS file system, to address the
existing OCI format limitations.
Hi all!
This is a proof of concept driver written for PuzzleFS next-generation container file system [1]. I have included a brief summary. about puzzlefs below. This controller is based on the rust-next branch, in addition to which I have backed up the filesystem abstractions...
Regarding the development of the project, it is mentioned that it is intended to circumvent the limitations that arise when using container images in OCI (Open Container Initiative) format. PuzzleFS addresses issues such as efficient storage of duplicate data, direct mount capability, lto repeatable image creation and memory security.
for deduplication of repeated data in different containers the FastCDC algorithm is used (Fast Content-Defined Chunking), which works by breaking data into chunks of arbitrary size and maintaining a hashed index of the chunks processed.
Repeated chunks are stored once and indexed together for all FS layers, i.e. deduplication can cover different mount points (you can launch a new FS layer based on the existing one and use the data chunks it contains during deduplication). deduplication).
The repeatable build container images is achieved by defining a canonical representation of the format container image. Direct mounting allows you to mount an OCI container image from global shared storage without first unpacking it, using the content hash of the container manifest as an identifier.
Direct mount support is a key feature of puzzlefs and, together with fs-verity, provides data integrity. Currently, puzzlefs is implemented as a userspace filesystem (FUSE), although a read-only kernel filesystem driver is in the works.
The mechanism fs-verity can be used to verify the integrity of de the data in the terms of use of a shared storage that, when accessing the files, checks if the hashes specified in the binary index correspond to the actual content.
Regarding the programming language, it is mentioned that the Rust language was chosen because it combines the high performance of the resulting code with safe memory capabilities, which reduces the risk of vulnerabilities caused by problems such as memory access after freeing and memory overruns. buffer. Using Rust for the kernel module also made it possible to share code across kernel and userspace components to create a single secure implementation.
Finally, it is mentioned that other objectives of the project include the construction and assembly of images very fast, the ability to use an optional intermediate stage for image canonicalization, optional mtree-style FS tree traversals when using a layered structure, casync style changes, reduced duplication, direct mount support, and memory security guarantees, some inspired by the OCIv2 design document, among other things.
It is worth mentioning that up to now the implementation of this file system is still in the prototype stage, so its use or implementation in production environments is not recommended, but those interested should know that it is compatible with building with the rust-next Linux kernel branch.
Finally, for those interested in being able to learn more about it, they should know that the project code is open under the Apache 2.0 and MIT licenses and you can check the details of theNote in the following link.