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.
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.
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.
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?
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.