// learn · linux · rhcsa · 9 min

Stratis & VDO.

Stratis is RHEL's modern storage management layer — thinly provisioned pools and filesystems, snapshots, all driven by stratisd. VDO adds inline dedupe and compression beneath the filesystem. Both build on the LVM + XFS you already know.

Stratis and VDO animated tutorial. Stratis pools and thinly provisioned XFS filesystems on top, stratis snapshots, and VDO (Virtual Data Optimizer) for inline deduplication and compression. RHCSA EX200 ready.
// stratis & vdo

Two modern RHEL storage layers built on what you already know. Stratis orchestrates LVM + XFS into friendly thinly provisioned pools; VDO transparently dedupes and compresses underneath.

// before you start
you should know
  • ·The LVM stacking lesson (thin provisioning concept)
  • ·The filesystems/mounts lesson
  • ·Comfortable as root
by the end you'll

Create a Stratis pool and thin XFS filesystem on it, snapshot it, and explain when to layer VDO underneath.

pace: 9 minutes

stratis pool — step 1 / 6 · what & why
📦 stratis pool · mypool0 / 100 GiB used
no filesystems yet — `stratis filesystem create mypool data`

What Stratis is

Stratis isn't a new filesystem — it orchestrates LVM (for thin pools) + XFS (for the filesystems on top) behind one friendly CLI (`stratis`). You create a POOL from one or more block devices, then carve thinly provisioned FILESYSTEMS out of the pool. Snapshots, growth, and pool expansion are all one-liners. Driven by the stratisd daemon.

$systemctl enable --now stratisd
$stratis pool list
// key insight

Stratis is "LVM thin + XFS, one CLI". VDO is "dedupe + compression, below your FS". They're independent — use Stratis when you want easier storage management; layer VDO when the workload has heavy duplication.

// exam-ready · stratis & vdo
$systemctl enable --now stratisd
$stratis pool create POOL DEV [DEV ...]
$stratis pool list
$stratis pool add-data POOL DEV
$stratis filesystem create POOL FS
$stratis filesystem list
$stratis filesystem snapshot POOL FS SNAP
$stratis filesystem destroy POOL FS
$/dev/stratis/POOL/FS
$x-systemd.requires=stratisd.service
$vdo create --name=N --device=DEV --vdoLogicalSize=1T
$mkfs.xfs -K /dev/mapper/N
$vdo list / status
$vdostats --human-readable
$vdo growLogical / growPhysical
$vdo remove --name=N
// check yourself
4 quick questions
Q1

What does Stratis actually USE under the hood?

Q2

You created a Stratis filesystem of 1 TiB on a pool with 100 GiB of backing storage. Is that broken?

Q3

What is VDO and where does it sit in the stack?

Q4

Which workload is VDO most likely to help?

These aren't graded — they're just for active recall, which is what actually makes the lesson stick.

💾
// the layer underneath

LVM stacking

Stratis is LVM thin + XFS with a friendlier face. Solidify the LVM stack first and Stratis just clicks into place.

open →

Read this lesson as text6 chapters · quiz answers

  1. 01What Stratis is

    Stratis isn't a new filesystem — it orchestrates LVM (for thin pools) + XFS (for the filesystems on top) behind one friendly CLI (stratis). You create a POOL from one or more block devices, then carve thinly provisioned FILESYSTEMS out of the pool. Snapshots, growth, and pool expansion are all one-liners. Driven by the stratisd daemon.

    • $ systemctl enable --now stratisd — the management daemon
    • $ stratis pool list — no pools yet

  2. 02Create a pool

    stratis pool create mypool /dev/sdb /dev/sdc makes a pool that aggregates those devices. The total backing capacity is the sum. Devices are owned by the pool — don't poke at them with parted/mkfs anymore. Add more capacity later with pool add-data.

    • $ stratis pool create mypool /dev/sdb /dev/sdc — make the pool
    • $ stratis pool list — see size + usage
    • $ stratis pool add-data mypool /dev/sdd — grow the pool later

  3. 03Create thinly provisioned filesystems

    stratis filesystem create mypool data creates an XFS on the pool that LOOKS huge (1 TiB by default) but only consumes pool space as you actually write data. That's thin provisioning. You can carve many such filesystems out of one pool — collectively their virtual sizes can exceed the backing pool, as long as actual usage stays within it. The path is /dev/stratis/mypool/data, ready to mount.

    • $ stratis filesystem create mypool data — thin XFS on the pool
    • $ mkdir /data && mount /dev/stratis/mypool/data /data — mount as usual
    • $ echo '/dev/stratis/mypool/data /data xfs defaults,x-systemd.requires=stratisd.service 0 0' >> /etc/fstab — fstab (needs that requires=)

  4. 04Snapshots — instant, copy-on-write

    stratis filesystem snapshot mypool data data-snap creates a snapshot of the live filesystem in O(1). It shares blocks with the original; only divergent writes consume new pool space. Perfect for pre-upgrade safety or consistent backup. Mount it like any FS at /dev/stratis/mypool/data-snap.

    • $ stratis filesystem snapshot mypool data data-snap — instant CoW snapshot
    • $ mount /dev/stratis/mypool/data-snap /mnt/snap — mount the snapshot
    • $ stratis filesystem destroy mypool data-snap — delete when done

  5. 05VDO — inline dedupe + compression

    VDO (Virtual Data Optimizer) sits BELOW the filesystem on a block device. It transparently deduplicates identical blocks and compresses everything before writing to the underlying storage. A 10 TB VDO volume on 4 TB of actual disk can be realistic for VM images or backups (high dedupe). Workflow: vdo create → mkfs → mount. Trade-off: CPU and memory for capacity savings.

    • $ vdo create --name=vdo1 --device=/dev/sdb --vdoLogicalSize=1T — 1 TiB virtual on /dev/sdb
    • $ mkfs.xfs -K /dev/mapper/vdo1 — -K skips discards (VDO handles it)
    • $ mount /dev/mapper/vdo1 /vdata — mount

  6. 06Watch the savings

    vdostats --human-readable shows the savings ratio — logical (what apps see) vs physical (what's actually on disk). Workloads with lots of duplicate data (VM images, container layers, backups) can hit 5-10× savings. Random or already-compressed data (encrypted, JPEGs, video) won't dedupe — VDO is workload-dependent. vdo list and vdo status for management.

    • $ vdostats --human-readable — savings ratio
    • $ vdo list — your VDO volumes
    • $ vdo status — detailed config + stats
    • $ vdo growLogical / growPhysical — resize

Quiz — answers

What does Stratis actually USE under the hood?
→LVM (for thinly provisioned pools) + XFS (for the filesystems on top), orchestrated by stratisd via the stratis CLI.Stratis is a layer of orchestration, not a new on-disk format. It uses well-understood components (LVM thin + XFS) under a friendlier UX. That's why an admin who knows LVM and XFS can pick it up quickly.
You created a Stratis filesystem of 1 TiB on a pool with 100 GiB of backing storage. Is that broken?
→No — that's the point of thin provisioning. The 1 TiB is virtual; pool space is consumed only as data is actually written. The pool can also be expanded later by adding more devices.Thin = present a larger logical size than physical. Multiple thin FSes can share one pool, with their sums exceeding it, as long as actual usage stays within. Keep an eye on pool usage; if it fills, writes start failing.
What is VDO and where does it sit in the stack?
→A BLOCK-LAYER transformer that sits beneath the filesystem on a device. It inline-deduplicates identical blocks and compresses the rest before writing to the underlying disk.VDO is below your filesystem. mkfs runs on the VDO device (/dev/mapper/vdoX), so the FS sees a fat virtual block device while VDO trades CPU and memory to shrink the actual on-disk footprint.
Which workload is VDO most likely to help?
→VM disk images and container layers — they often share huge runs of identical blocks, so dedupe ratios of 5-10× are achievable.VDO needs duplicate or compressible data to save anything. VM/container imagery is a great fit; encrypted or pre-compressed data is near-incompressible and won't dedupe (high entropy = low ratio).
// more in linux

keep going — these pair well with what you just learned.

see all linux →
🛡️

SELinux contexts

Why Apache can't read your file. Watch the policy engine decide — and learn the workflow for fixing denials. RHCSA-ready.

8 min · interactiveopen →
⚡

Linux boot process

From power button to login prompt. Every stage in the chain — UEFI, GRUB, kernel, initramfs, systemd — with the rescue moves that save you. RHCSA-ready.

9 min · interactiveopen →
💾

LVM stacking

Layer-by-layer build of an LVM stack: disks → PVs → VG → LVs → filesystem. Then extend live and snapshot. RHCSA-ready.

8 min · interactiveopen →

See also

back to RHCSA trackall lessons