Encryption for filesystems with advanced features new fscrypt functionality
summary
fscrypt gains per-extent encryption with a key stored in each extent, enabling reflink and snapshot-safe encryption rather than inode-only keys. btrfs patches implement this on the block-crypto side, add a block-crypto callback for checksums, and accept ~4.5 extents per inode on average (more metadata cost). Current minimal design supports basic per-extent reads/writes and reflinks, lacks nested encrypted subvolume support and online key-rotation, and is not yet upstream.
AI-written summary · about
chapters (6)
- 0:00Introduction to FS script
- 2:29Working with FS script
- 8:19Extent-based encryption
- 11:19Development history
- 15:48Future goals and challenges
- 23:52Q&A and discussion
related talks
33mBringing fscrypt Encryption to CephFS Userspace
30mOpenZFS and Linux
32mSecurity Features for UBIFS
20mBtrfs: The Butter of Fedora
28mSpeculative Encryption on GPU Applied to Cryptographic File Systems
36mFlash Friendly File System
32mfs-verity: Native File-based Authenticity
34mAuthenticated and Encrypted Storage on Embedded Linux