Btrfs at Scale: How Meta Depends on Btrfs for Our Entire Infrastructure
summary
Meta runs Btrfs as the fleet root filesystem across millions of machines, shipping send/receive base images several times a week and snapshotting at container startup for an instant snapshot runtime that cuts startup time to seconds. Btrfs compression reduces SSD writes (a base image ~11 GB compressed -> ~22 GB expanded) and cut MySQL binlog size to ~45% of original reclaiming ~5% of global capacity. Async discard and send-stream v2 (encoded read/write) remove discard latency and slash receive CPU and time.
AI-written summary · about
chapters (16)
- 0:00Introduction to Btrfs
- 1:28Meta internal use cases
- 3:45Container management
- 6:06Development and CI systems
- 8:11Seed devices and security
- 9:30Q&A: Snapshot space
- 11:41Q&A: Features and use cases
- 14:37Adoption and reliability
- 16:26Q&A: Reliability and data
- 18:58Q&A: Performance and ZFS
- 22:08Q&A: Containers and DBs
- 25:27I/O isolation and discard
- 27:24Technical improvements
- 33:13Future work and roadmap
- 37:10Scalability and memory
- 38:40Q&A: Hardware integration
related talks
20mBtrfs: The Butter of Fedora
30mOpenZFS and Linux
23mBtrfs RAID on zoned devices
15mcontainer-snap: Atomic Updates from OCI Images using Podman’s Btrfs Driver
11mImmutable Linux systems and how they work
15mLightning Talk: EROFS: An Image-based Filesystem for Containers
38msystemd @ Meta: From upstream to production
33mEncryption for filesystems with advanced features new fscrypt functionality