Support for shrinking a VDO volume

[DemiMarie]

It would be nice to be able to shrink a VDO volume. Online (as in ext4) would be ideal, but even offline would be useful.

[corwin]

While it is possible to implement this in VDO, it is quite a lot of work and is not currently on our road map.

What is you use case?

[DemiMarie]

Desktop and laptop systems. It is quite common for users to decide they need to repartition their storage in various ways. For instance, they might need to expand the EFI System Partition or /boot.

[tigerblue77]

I do agree with this suggestion. Maybe it could be great to first develop the ability to shrink a VDODataLV and, in a second development, the ability to shrink a VDOPoolLV

[raeburn]

Given the decoupling of the logical address range and the physical storage size that VDO provides, they’re two separate questions.

Shrinking the data LV isn’t hard, in fact:

[root@test-host]# df -h /mnt/VDOdir/
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/vdo1-vdo0   20G   24K   20G   1% /mnt/VDOdir

(Yes, I have a volume group “vdo1” containing a logical volume “vdo0”, due in part to some silliness with the historical way our test infrastructure was set up and how it interacts with the newfangled LVM support.)

[root@test-host]# lvresize --resizefs --size +10G vdo1/vdo0 
  Size of logical volume vdo1/vdo0 changed from 20.00 GiB (5120 extents) to 30.00 GiB (7680 extents).
  Logical volume vdo1/vdo0 successfully resized.
resize2fs 1.46.3 (27-Jul-2021)
Filesystem at /dev/mapper/vdo1-vdo0 is mounted on /mnt/VDOdir; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 4
The filesystem on /dev/mapper/vdo1-vdo0 is now 7864320 (4k) blocks long.

[root@test-host]# df -h /mnt/VDOdir/
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/vdo1-vdo0   30G   24K   30G   1% /mnt/VDOdir
[root@test-host]# lvresize --resizefs --size -5G vdo1/vdo0 
Do you want to unmount "/mnt/VDOdir" ? [Y|n] y
fsck from util-linux 2.37.4
/dev/mapper/vdo1-vdo0: 11/1966080 files (0.0% non-contiguous), 167442/7864320 blocks
resize2fs 1.46.3 (27-Jul-2021)
Resizing the filesystem on /dev/mapper/vdo1-vdo0 to 6553600 (4k) blocks.
The filesystem on /dev/mapper/vdo1-vdo0 is now 6553600 (4k) blocks long.

  WARNING: /dev/vdo1/vdo0: Discarding 5.00 GiB at offset 26843545600, please wait...
  Size of logical volume vdo1/vdo0 changed from 30.00 GiB (7680 extents) to 25.00 GiB (6400 extents).
  Logical volume vdo1/vdo0 successfully resized.
[root@test-host]# df -h /mnt/VDOdir/
Filesystem             Size  Used Avail Use% Mounted on
/dev/mapper/vdo1-vdo0   25G   24K   25G   1% /mnt/VDOdir
[root@test-host]# 

Shrinking the logical size of the LV doesn’t reduce the logical address space of the VDO device -- we don’t currently support that -- but it shouldn’t be impossible to add. It also probably wouldn’t gain much over simply doing a discard/trim over the range in question.

It’s shrinking the physical storage that’s hard, though as noted there are a few use cases where it might be handy on rare but important occasions: Repartitioning the underlying disk. Temporarily adding disk space due to running out of space, and then removing the extra disk after doing some cleanup. Nothing that’s likely to happen every day, but not unheard of either.

Since there’s no mapping from physical storage regions back to the logical addresses using them, you potentially have to scan the entire logical address map looking for anything that maps into the physical region you want to get rid of, and relocate those blocks and update both the logical address map and the deduplication index. (Going through the normal write path might be the easiest way to do those updates.)

Also, after a system crash mid-way through, we don’t want to be left in some weird state where we’ve got more blocks allocated than before and don’t know to automatically fix it (presumably by finishing the scanning and relocating process), so some state should probably be recorded in such a way that VDO can automatically recover to whatever degree is necessary on startup. Maybe the scan and relocation should be completed but not the resizing? Depends how things are designed, and maybe the context…