Dne 17. 10. 22 v 15:41 Erwin van Londen napsal(a):
From the looks of it the disk, as provisioned out of an Azure pool, is likely
backed by an enterprise raid array. When you provision the pools with
discard_passdown the removal of the snapshot will also be pushed down to the
underlying hypervisor or disk array. You would need to wait till that process
is completed in order to make any comparisons.
ThinVolGrp-ThinDataLV-tpool: 0 1006632960 thin-pool 1 4878/4145152
8325/7864320 - rw discard_passdown queue_if_no_space - 1024
As per man page
--discards passdown|nopassdown|ignore
Specifies how the device-mapper thin pool layer in the kernel should handle
discards. ignore causes the thin pool to ignore discards. nopassdown causes the
thin pool to process discards itself to allow reuse of unneeded extents in the
thin pool. passdown causes the thin pool to process discards itself (like
nopassdown) and pass the discards to the underlying device.
Try the same operation after changing the thin volume
lvchange --discards nopassdown VG/ThinPoolLV
Discard here is likely irrelevant - since there will likely no blocks for
discarding.
When the user removes thin LV (which happens to be sharing its block with
some other thin LV (origin -> snapshot)) there is just some metadata update
reducing sharing of blocks with origin thinLV - so nothing to be discard for
data (since snapshot is removed after its creation without any use - only if
the origin would be meanwhile in this short period of time changed
dramatically - then exclusively owned parts of such snapshot may be discarded)
Regards
Zdenek
_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
