https://github.com/msg555/ctrfs

ctrfs, Container File System, a file system specialized for storing and transmitting container images.
https://github.com/msg555/ctrfs

Last synced: about 2 months ago
JSON representation

ctrfs, Container File System, a file system specialized for storing and transmitting container images.

• Host: GitHub
• URL: https://github.com/msg555/ctrfs
• Owner: msg555
• License: other
• Created: 2021-03-22T01:08:41.000Z (almost 5 years ago)
• Default Branch: master
• Last Pushed: 2021-05-27T21:10:09.000Z (almost 5 years ago)
• Last Synced: 2024-06-19T20:59:30.438Z (over 1 year ago)
• Language: Go
• Homepage:
• Size: 247 KB
• Stars: 0
• Watchers: 2
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

README

          
**Work in progress, simply using github to better track progress at the moment.**

### Goals

This project will aim to implement a file-level content-addressed backing store

that can be mounted, imported, exported, shared, and used as an additional

storage engine for container systems.

ctrfs is designed to be the engine for read/write container file systems. It is

specialized for containers by observing the following special requirements of

container images.

* There is a high degree of data duplication between layers of different images.

 * Data is deduplicated at the block level across all layers/images

 * Pushing/pulling to registry is done at the file level using content addressing with metadata stored separately

* Overlay copy-up can be slow on file systems that do not support reflinks (check/measure this)

 * Persistent data structures are used and data is "copied-up" a single block at a time

 * Only dirty blocks need to be written back to central storage on commit.

* Image building is the most common reason to write to the container layer.

 * There is no journaling

 * fsync calls are ignored by default

 * All writes are asynchronous and written only to cache sychronously

 * Important persistant data used by a container should be written to a separate volume

* ctrfs also fixes some compatibility issues

 * Hardlinks work as expected after committing

Other notes

* Tree data will be content addressed

* Hardlinks are supported through special inode remapping structures