Example commands for common LVM related tasks.
Extend VG containing the LV with additional PV before conversion.
# vgextend vgdev /dev/nvme0n1p2
# lvconvert --type raid1 --mirrors 1 vgdev/backup /dev/nvme0n1p2
List currently used devices and sync status:
# lvs -a -o +devices
Run scrubbing – a full scan of RAID LV, which verifies RAID metadata, LV data and parity blocks:
# lvchange --syncaction check /dev/vgdev/backup
If problems are found, this is denoted by m
on 9th bit of attributes displayed
by lvs
:
$ cat /tmp/lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
backup vgdev rwi-aor-m- 4.00g 100.00
In such case repair ir required. As of LVM tools 2.03.21(2) (2023-04-21)
lvchange --syncaction repair
is unable to deduce which data is correct. The
only safe choice is to rebuild PV on the failed device:
# lvchange --rebuild /dev/sdb1 /dev/vgdev/backup
As of LVM tools 2.03.21(2) (2023-04-21) man lvmraid
says:
Integrity limitations
[…] The following are not yet permitted on RAID LVs with integrity: lvreduce, pvmove, snapshots, splitmirror, raid syncaction commands, raid rebuild.
That means commands like lvchange --syncaction repair
or lvchange --rebuild
won’t work as expected.
If RAID1 with integrity LV requires refresh (partial synchronization) due to e.g. device write errors, but both PVs are otherwise available, take the following steps to fix it:
# lvconvert --raidintegrity n vgdev/backup
# lvchange --rebuild /dev/sda vgdev/backup
lvchange --synaction repair
could theoretically refresh RAID1. But due to
lack of integrity layer, it cannot tell which drive contains uncorrupted data,
so the process must be performed manually:
# lvconvert --splitmirrors 1 --name backup_split vgdev/backup
# sha512sum /dev/vgdev/backup /dev/vgdev/backup_split
# fsck.ext4 -n -f /dev/vgdev/backup
# fsck.ext4 -n -f /dev/vgdev/backup_split
# mount /dev/vgdev/backup /mnt/mirror1
# mount /dev/vgdev/backup_split /mnt/mirror1
# rsync -d /mnt/mirror1 /mnt/mirror2