VDO
Purpose
General notes on using VDO [1] [2]
Encryption with LUKS
This is a work in progress as my test backup drive keeps getting corrupted.
- Working with a 2TB external disk
- Created GPT table on disk (in this example /dev/sde) using parted, then created partition using gpart that used all available space.
- Setup encryption
[root@natasha ~]# cryptsetup luksFormat /dev/sde1 WARNING! ======== This will overwrite data on /dev/sde1 irrevocably. Are you sure? (Type uppercase yes): YES Enter passphrase for /dev/sde1: Verify passphrase:
- Open the encrypted volume, and setup VDO.
[root@natasha ~]# cryptsetup luksOpen /dev/sde1 enc_backup
Enter passphrase for /dev/sde1:
[root@natasha ~]# vdo create --name=backup_vdo --device=/dev/mapper/enc_backup --vdoLogicalSize=4T
Creating VDO backup_vdo
The VDO volume can address 1 TB in 1022 data slabs, each 2 GB.
It can grow to address at most 16 TB of physical storage in 8192 slabs.
If a larger maximum size might be needed, use bigger slabs.
Starting VDO backup_vdo
Starting compression on VDO backup_vdo
VDO instance 0 volume is ready at /dev/mapper/backup_vdo
- Create LVM partition
[root@natasha ~]# pvcreate /dev/mapper/backup_vdo
Physical volume "/dev/mapper/backup_vdo" successfully created.
[root@natasha ~]# vgcreate backup /dev/mapper/backup_vdo
Volume group "backup" successfully created
[root@natasha ~]# lvcreate -l 100%VG backup --name backuptest
Logical volume "backuptest" created.
[root@natasha ~]# mkfs.ext4 -E nodiscard /dev/mapper/backup-backuptest
mke2fs 1.45.4 (23-Sep-2019)
Creating filesystem with 1073740800 4k blocks and 268435456 inodes
Filesystem UUID: 30475cde-9f57-4a6f-8067-8dbbcbef127f
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done
- After mounting everything I have the following tree.
[root@natasha ~]# lsblk /dev/sde
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sde 8:64 0 2T 0 disk
└─sde1 8:65 0 2T 0 part
└─enc_backup 253:9 0 2T 0 crypt
└─backup_vdo 253:10 0 4T 0 vdo
└─backup-backuptest 253:11 0 4T 0 lvm /mnt/backup
- At this point I am writing random data to the disk to see if I can trigger the corruption I was getting previously.
Grow Logical VDO Size
I have a SAMBA share used to mirror a directory from another server. This was intended to test VDO. The problem is that the kernel reports the disk is now full, but the physical usage is no where near full.
- Size of the disk.
sudo lsblk /dev/nvme2n1 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme2n1 259:3 0 300G 0 disk └─datafeed 253:0 0 295.4G 0 vdo /mnt/data
- Here I am told the mount point is full.
sudo df -hT /dev/mapper/datafeed Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/datafeed xfs 296G 296G 160K 100% /mnt/data
- But when checking vdo stats, we see it very much empty
sudo vdostats --human-readable Device Size Used Available Use% Space saving% /dev/mapper/datafeed 300.0G 80.3G 219.7G 26% 74%
- Now I grow the logical volume size
sudo vdo growLogical --name=datafeed --vdoLogicalSize=500G sudo lsblk /dev/nvme2n1 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme2n1 259:3 0 300G 0 disk └─datafeed 253:0 0 500G 0 vdo /mnt/data
- Grow XFS and check changes
sudo xfs_growfs /dev/mapper/datafeed ......... sudo df -hT /dev/mapper/datafeed Filesystem Type Size Used Avail Use% Mounted on /dev/mapper/datafeed xfs 500G 296G 205G 60% /mnt/data
