If one is used to adminning fleets of servers with regular LVM, eg adding disks and then adding those disks to PVs and then extending LVs etc, regular LVM is a beautiful and easy process, and one gets accustomed to the ease and comfort of regular LVM.
However, if you come across a shop that uses LVM thin provisioning, it's a completely different ball game because you now are working with the thin volume as the basis, and if you don't account for that and and expand that first before expanding your LVs that live in the thin volume, you will have big problems, and it's so easy to corrupt your filesystem if you expand LVs incorrectly without taking into account the thin volume. EG even if you have the space in the volume group, if you don't expand the thin volume first before then expanding an LV, you will absolutely corrupt your LV's filesystem at some point. And often the corruption won't happen until the space finally gets used in the LV where it encroaches on the max size of the thin volume. Eg could be months or a year later.
Also the documentation around adding disks and expanding PVs/VGs/LVs when you have thin volumes is poor to non-existent.
I despise LVM thin provisioning.
TL;DR - do not consider implementing LVM thin provisioning into your systems unless you have an expert understanding of LVM thin provisioning. Trust me, even if you can manage regular LVM in your sleep, LVM thin provisioning is an entirely different beast, and if you think otherwise, you will break machines.
simoncion•1mo ago
> ...until the space finally gets used in the LV where it encroaches on the max size of the thin volume.
I'll assume that this means "once enough data is written to the LV to fill the space currently allocated to the thin LV". Do correct me if my assumption is incorrect.
Did you disable thin LV monitoring and automated resizing? By default, writes to full thin LVs are delayed until the LV is resized or return a write error if the LV hasn't been resized after (a default of) 60 seconds. In my experience, the automated thin LV resizing worked quickly and painlessly. lvmthin(7) says this about the default behavior:
Writes to thin LVs are accepted and queued, with the expectation that pool data space will be extended soon. Once data space is extended, the queued writes will be processed, and the thin pool will return to normal operation.
While waiting to be extended, the thin pool will queue writes for up to 60 seconds (the default). If data space has not been extended after this time, the queued writes will return an error to the caller, e.g. the file system. This can result in file system corruption for non-journaled file systems that may require repair. When a thin pool returns errors for writes to a thin LV, any file system is subject to losing unsynced user data.
> Also the documentation around adding disks and expanding PVs/VGs/LVs when you have thin volumes is poor to non-existent.
What changes with PV and VG management when you have thin LVs? I used thin LVs for a while and found that everything other than the automated resizing seemed to be the same as with "thick" LVs. What did I miss?
cramcgrab•1mo ago
Zfs thin is way better, adjusts on the fly and can handle things like dedupe and compression. Lots of good things in zfs because it’s the filesystem and the volume manager.
eru•1mo ago
Basically any copy-on-write filesystem should give you snapshots as described in the article for 'free'?
And you can get the over-commitment they describe in their point 1 by just putting the users on the same file system with some per-user quota?
XorNot•1mo ago
"any" yes their honestly aren't that many and I'm not aware of any which are as available and battle-tested as ZFS. It's been decades at this point and it's a well-proven, capable filesystem.
indigodaddy•1mo ago
However, if you come across a shop that uses LVM thin provisioning, it's a completely different ball game because you now are working with the thin volume as the basis, and if you don't account for that and and expand that first before expanding your LVs that live in the thin volume, you will have big problems, and it's so easy to corrupt your filesystem if you expand LVs incorrectly without taking into account the thin volume. EG even if you have the space in the volume group, if you don't expand the thin volume first before then expanding an LV, you will absolutely corrupt your LV's filesystem at some point. And often the corruption won't happen until the space finally gets used in the LV where it encroaches on the max size of the thin volume. Eg could be months or a year later.
Also the documentation around adding disks and expanding PVs/VGs/LVs when you have thin volumes is poor to non-existent.
I despise LVM thin provisioning.
TL;DR - do not consider implementing LVM thin provisioning into your systems unless you have an expert understanding of LVM thin provisioning. Trust me, even if you can manage regular LVM in your sleep, LVM thin provisioning is an entirely different beast, and if you think otherwise, you will break machines.
simoncion•1mo ago
I'll assume that this means "once enough data is written to the LV to fill the space currently allocated to the thin LV". Do correct me if my assumption is incorrect.
Did you disable thin LV monitoring and automated resizing? By default, writes to full thin LVs are delayed until the LV is resized or return a write error if the LV hasn't been resized after (a default of) 60 seconds. In my experience, the automated thin LV resizing worked quickly and painlessly. lvmthin(7) says this about the default behavior:
> Also the documentation around adding disks and expanding PVs/VGs/LVs when you have thin volumes is poor to non-existent.What changes with PV and VG management when you have thin LVs? I used thin LVs for a while and found that everything other than the automated resizing seemed to be the same as with "thick" LVs. What did I miss?