Rocky 10: LVM snapshots and merge rollback (tested in a VM)

Test scope

In a Rocky Linux 10.2 virtual machine (kernel 6.12.0-211.16.1.el10_2, LVM 2.03.36): loop-backed PV/VG/LV with XFS, fsfreeze + lvcreate -s, mount -o ro,nouuid, lvconvert --merge, then remount and verify. Log: plans/content-expansion/evidence/logs/rocky-lvm-snapshot.log.

This is a real EL10 kernel in a VM, not a container sharing the host kernel, so kernel-level snapshot behaviour is trustworthy here.

Why fsfreeze comes first

sudo fsfreeze -f /mnt/data
sudo lvcreate -y -s -L 300M -n snap /dev/vglab/data
sudo fsfreeze -u /mnt/data

XFS keeps a journal: snapshotting a mounted filesystem can capture metadata changes whose data has not reached disk, leaving the snapshot inconsistent. fsfreeze -f flushes and suspends writes; -u resumes.

Skipping fsfreeze does not necessarily fail — the snapshot may mount and still hold inconsistent data. That is worse than an error.

Mount the snapshot read-only with nouuid

sudo mount -o ro,nouuid /dev/vglab/snap /mnt/snap
ls /mnt/snap
cat /mnt/snap/a.txt

a.txt
before-snapshot

The snapshot carries the origin’s XFS UUID, and the kernel refuses two filesystems with the same UUID; nouuid skips that check. Read-only mounting also protects the snapshot from writes.

Change data: the snapshot stays frozen

echo "after-snapshot-change" > /mnt/data/b.txt
rm -f /mnt/data/a.txt
ls /mnt/data

b.txt

The origin now holds only b.txt, while the snapshot still shows a.txt with before-snapshot — two distinct points in time.

Merge rollback and the EBUSY trap

sudo umount /mnt/data
sudo lvconvert --merge /dev/vglab/snap
sudo lvchange -an vglab/data
sudo lvchange -ay vglab/data

Merging of volume vglab/snap started.
vglab/data: Merged: 100.00%

100% does not mean mountable. In testing, mounting right after lvchange -ay alone gave:

mount: /mnt/data: /dev/mapper/vglab-data already mounted or mount point busy.

A full deactivate/reactivate cycle (lvchange -an then -ay) was required before the mount succeeded. This is the most valuable finding on the page — Merged: 100.00% invites you to stop too early.

Verify the rollback

sudo mount /dev/vglab/data /mnt/data
ls /mnt/data
cat /mnt/data/a.txt
ls /mnt/data/b.txt

a.txt
before-snapshot
ls: cannot access '/mnt/data/b.txt': No such file or directory

a.txt is back and b.txt is gone: every write after the snapshot point was rolled back. Do this step — a merge percentage is not verification.

Playable end-to-end sequence

The recording below plays the whole loop in order — build the volume, freeze, snapshot, change data, read the snapshot, merge, reactivate, verify (the .cast is 871 bytes and never autoplays):

LVM snapshot and merge rollback (Rocky Linux 10.2) ▶ 播放终端演示 / Play

文字版（命令与输出） / Text transcript

# 1. build a loop-backed LV for the lab
truncate -s 1G /var/tmp/cast.img
pvcreate -y "$L"; vgcreate vglab "$L"; lvcreate -y -L 800M -n data vglab
mkfs.xfs -q /dev/vglab/data; mount /dev/vglab/data /mnt/data
echo before > /mnt/data/a.txt

# 2. freeze, snapshot, unfreeze
fsfreeze -f /mnt/data
lvcreate -y -s -L 200M -n snap /dev/vglab/data
fsfreeze -u /mnt/data
LV   LSize   Attr
data 800.00m owi-aos---
snap 200.00m swi-a-s---

# 3. change the origin, then read the snapshot
echo after > /mnt/data/b.txt; rm -f /mnt/data/a.txt
mount -o ro,nouuid /dev/vglab/snap /mnt/snap
cat /mnt/snap/a.txt      # before

# 4. merge back and reactivate
lvconvert --merge /dev/vglab/snap
vglab/data: Merged: 100.00%
lvchange -an vglab/data; lvchange -ay vglab/data

# 5. verify the rollback
cat /mnt/data/a.txt      # before

Commands and output are real; the player script is only fetched when you press play.

Common traps

• No fsfreeze: the snapshot may be inconsistent and only fail on restore;
• Mounting without nouuid: UUID clash;
• Mounting right after merge: EBUSY; use lvchange -an && -ay first;
• Merging while mounted: lvconvert --merge requires the origin unmounted.

Practice: run the whole snapshot cycle

sudo dnf install -y lvm2 xfsprogs
truncate -s 2G /var/tmp/snap.img
L=$(sudo losetup -f --show /var/tmp/snap.img)
sudo pvcreate -y "$L" && sudo vgcreate vglab "$L"
sudo lvcreate -y -L 1G -n data vglab
sudo mkfs.xfs -q /dev/vglab/data
sudo mkdir -p /mnt/data /mnt/snap && sudo mount /dev/vglab/data /mnt/data
echo before | sudo tee /mnt/data/a.txt >/dev/null && sync
sudo fsfreeze -f /mnt/data
sudo lvcreate -y -s -L 300M -n snap /dev/vglab/data
sudo fsfreeze -u /mnt/data
sudo rm /mnt/data/a.txt
sudo umount /mnt/data && sudo lvconvert --merge /dev/vglab/snap
sudo lvchange -an vglab/data && sudo lvchange -ay vglab/data
sudo mount /dev/vglab/data /mnt/data && cat /mnt/data/a.txt

Checks:

1. lvs -o lv_attr shows the snapshot starting with s
2. mount -o ro,nouuid reads before
3. The merge prints Merged: 100.00%
4. After rollback, cat /mnt/data/a.txt prints before

FAQ

常见问题

Is fsfreeze mandatory for snapshots?

For journaling filesystems such as XFS and ext4, yes — snapshotting a mounted filesystem without freezing can capture an inconsistent state that only surfaces during restore.

Why does the snapshot mount need nouuid?

It duplicates the origin UUID, and the kernel refuses two XFS filesystems with the same UUID; nouuid skips that check and pairs with ro for read-only access.

What if mount reports EBUSY after a 100% merge?

Run a full deactivate/reactivate cycle: lvchange -an vglab/data && lvchange -ay vglab/data, then mount. Deactivating and reactivating only via -ay was not enough in testing.

Next steps

• Growing storage: LVM growth
• XFS repair: XFS repair
• rsync backups: rsync incremental backup