Estimating dm-vdo storage savings
summary
vdoestimator scans directories or block devices and uses the same MurmurHash3 and LZ4 code as dm‑vdo to predict inline deduplication and compression savings. Index size is fixed at creation; a rule of thumb is 1 GiB index ≈ 10 TiB dedupe window of 4K blocks. Example runs: a source tree shows ~73% logical reduction predicted and actual dm‑vdo stats match closely; a 2+ TB Exchange backup set shows almost no compression and a sparse index drops dedupe by only ~2%. Tool is on GitHub.
AI-written summary · about
chapters (7)
- 0:00Intro
- 0:18VDO overview
- 7:10UDS implementation
- 9:12UDS configuration
- 13:47vdoestimator
- 16:01Command line
- 17:26Example output
related talks
39mThe Power of the Device Mapper - From Dm-cache To Dm-zoned
25mlvm2 and VDO will it blend ?
47mDAMO[N,S]?: Implementing Self-Driven Data Access-Aware Efficient Linux System
52mDAMON, DAMOS, and DAMO: Kernel Subsystems and User-Space Tools for Data Access...
30mSlimming down the journal
15mMapperX: Adaptive Metadata Maintenance for Fast Crash Recovery of DM-Cache Based...
19mKdump memory usage
42mDAMON Recipes: Ways to Save Memory Using a Linux Kernel Subsystem in the Real World