Defragmentation of LVM2 logical volumes

Question

Question: Is there a tool supporting de-fragmentation of LVM2 logical volumes? (Making their extents into consistent sequences)

Preferably by defining desired order of extents (something like "partition A on beginning of disk, B after A, but X on the end of PV")

Of course the following cases have to be considered:

• VG consists of one PV
• VG consists of many PV, but each LV sits on one PV
• VG consists of many PV, LVs have their extents across many PV

Whether partitions can be stripped or not, can be discussed.

Know-how: It's possible to move ranges of extents with pvmove , e.g. : pvmove --alloc anywhere /dev/sdb1:1000-1999 /dev/sdb1:0-999 .

Reason: Because moving many ranges manually with pvmove is purely repeatable thing (questionable if brainless or not), I was curious if there exists tool for automatizing/supporting this process. If not... maybe doing one by myself - do you think such tool would be useful for other people?

Solution 1

I've used LVM2 defragmenter before. It is not the simplest or best written, but it does the trick.

Solution 2

Well one more reason for defragmenting would be to reduce chances of data loss when shrinking a logical volume. A specific reason to shrink a logical volume is to allow expansion of /boot and similar partitions on an older MBR computer hard drive. In my case upgrading from LTS 16.04.03 to LTS 18.04.1 needs more than the 500MB allocated to /boot by the original default installation.

Haven't read the thousands of lines of source code for lvm2 but some of the online help/wiki hint that lvm2 uses pretty brute force truncation when straightforward logical volume shrink procedures are used - as in if files are allocated in the area released by shrinkage you probably will need to restore that list of files (potentially a wild goose chase in itself if application or system packages are involved - or if your user files list is very large).

Comments

[Gilles 'SO- stop being evil']

It's possible that there's no tool because there's no use case that requires it. I'm curious, why do you want to defragment? Is there a disk technology where there's a benefit for a typical extent size (4MB)?

[Grzegorz Wierzowiecki]

Let's consider traditional HardDrive (not SSD) performance characteristics - beginning of disk offers better performance than end. That's most important factor, why you might like to have extents related to some partition to be placed on beginning.

[Gilles 'SO- stop being evil']

For that kind of control, the simple way is to partition the disk into several physical volumes.

[Grzegorz Wierzowiecki]

But on the other hand it makes more mess in config files and all setup less flexible. I believe that solutions like mentioned by @JimParis LVM2 defragmenter or pvmove do the job.

[Grzegorz Wierzowiecki]

Looks interesting. I need to try it.

[Aquarius Power]

do you believe this defrag could make it easier to (based on it) implement/create a way to recover a LV partially as stated is possible (was done) here serverfault.com/a/665826/163750 ?

[H. Rittich]

If you want to shrink a logical volume, you should first shrink the filesystem stored on said volume. This can be done using commands like resize2fs or btrfs filesystem resize. After this operation the filesystem is only occupying the first n bytes of the volume, where n is the size you specified for shrinking the filesystem. Now, truncating/resizing the logical volume to any size larger than n bytes is safe. Neither defragmenting the LVM nor the file system will prevent or reduce any data loss! You will have to resize the filesystem!