add comments about LVM thin clones

PVE/Storage.pm

@@ -321,6 +321,9 @@ sub parse_vmid {
     return int($vmid);
 }
 
+# NOTE: basename and basevmid are always undef for LVM-thin, where the
+# clone -> base reference is not encoded in the volume ID.
+# see note in PVE::Storage::LvmThinPlugin for details.
 sub parse_volname {
     my ($cfg, $volid) = @_;
 
@@ -367,6 +370,9 @@ my $volume_is_base_and_used__no_lock = sub {
     return 0;
 };
 
+# NOTE: this check does not work for LVM-thin, where the clone -> base
+# reference is not encoded in the volume ID.
+# see note in PVE::Storage::LvmThinPlugin for details.
 sub volume_is_base_and_used {
     my ($cfg, $volid) = @_;
 
@@ -708,6 +714,7 @@ sub vdisk_free {
 
     # lock shared storage
     $plugin->cluster_lock_storage($storeid, $scfg->{shared}, undef, sub {
+	# LVM-thin allows deletion of still referenced base volumes!
 	die "base volume '$volname' is still in use by linked clones\n"
 	    if &$volume_is_base_and_used__no_lock($scfg, $storeid, $plugin, $volname);
 

PVE/Storage/LvmThinPlugin.pm

@@ -15,6 +15,12 @@ use PVE::JSONSchema qw(get_standard_option);
 # lvcreate -n pvepool -L 20G pve
 # lvconvert --type thin-pool pve/pvepool
 
+# NOTE: volumes which were created as linked clones of another base volume
+# are currently not tracking this relationship in their volume IDs. this is
+# generally not a problem, as LVM thin allows deletion of such base volumes
+# without affecting the linked clones. this leads to increased disk usage
+# when migrating LVM-thin volumes, which is normally prevented for linked clones.
+
 use base qw(PVE::Storage::LVMPlugin);
 
 sub type {
@@ -46,6 +52,9 @@ sub options {
     };
 }
 
+# NOTE: the fourth and fifth element of the returned array are always
+# undef, even if the volume is a linked clone of another volume. see note
+# at beginning of file.
 sub parse_volname {
     my ($class, $volname) = @_;