Hi, i'm sorry to bother you again with my ignorance of the DISCARD feature for block devices in general. after finding several ways to enable "discard=unmap" for oVirt disks (via standard GUI option for iSCSI disks or via "diskunmap" custom property for Cinder disks) i wanted to check in the guest for the effectiveness of this feature. to my surprise i couldn't find a difference between Linux guests with and without "discard=unmap" enabled in the VM. "lsblk -D" reports the same in both cases and also fstrim/blkdiscard commands appear to work with no difference. Why is this? Do i have to look at the underlying storage to find out what really happens? Shouldn't this be visible in the guest OS? thx matthias _______________________________________________ Users mailing list Users(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users

Hi Idan, thanks for your answer. But i'm still confused, because i thought that the content of /sys/block/dm-X/queue/discard* in the VM OS should depend on the setting of the "discard=(unmap|ignore)" setting in the qemu-kvm command. Unexpectedly it's the same in both cases (it's >0, saying discard is 'on'). I was then trying to inquire about the TRIM/UNMAP capability of block devices in the VM with "sdparm -p lbp /dev/sdx", but i always get "Logical block provisioning (SBC) mode subpage failed".

From what I know, the file in sysfs and the VM flag are not related.

I know i can (and should) look at the storage array to see if TRIM/UNMAP _actually_ works, but documentation (https://www.kernel.org/doc/Do cumentation/block/queue-sysfs.txt) says it should be visible beforehand to my understanding. Regards Matthias Am 2018-02-11 um 08:55 schrieb Idan Shaby: > Hi Matthias, > > When the guest executes a discard call of any variation (fstrim, > blkdiscard, etc.), the underlying thinly provisioned LUN is the one that > changes - it returns the unused blocks to the storage array and gets > smaller. > Therefore, no change is visible to the guest OS. > If you want to check what has changed, go to the storage array and check > what's the size of the underlying thinly provisioned LUN before and after > the discard call. > > The answer for your question and some more information can be found in > the feature page [1] (needs a bit of an update, but most of it is still > relevant). > If you got any further questions, please don't hesitate to ask. > > > Regards, > Idan > > [1] Pass discard from guest to underlying storage - > https://www.ovirt.org/develop/release-management/features/st > orage/pass-discard-from-guest-to-underlying-storage/ > > On Thu, Feb 8, 2018 at 2:08 PM, Matthias Leopold < > matthias.leopold(a)meduniwien.ac.at <mailto:matthias.leopold@medun > iwien.ac.at>> wrote: > > Hi, > > i'm sorry to bother you again with my ignorance of the DISCARD > feature for block devices in general. > > after finding several ways to enable "discard=unmap" for oVirt disks > (via standard GUI option for iSCSI disks or via "diskunmap" custom > property for Cinder disks) i wanted to check in the guest for the > effectiveness of this feature. to my surprise i couldn't find a > difference between Linux guests with and without "discard=unmap" > enabled in the VM. "lsblk -D" reports the same in both cases and > also fstrim/blkdiscard commands appear to work with no difference. > Why is this? Do i have to look at the underlying storage to find out > what really happens? Shouldn't this be visible in the guest OS? > > thx > matthias > > _______________________________________________ > Users mailing list > Users(a)ovirt.org <mailto:Users@ovirt.org> > http://lists.ovirt.org/mailman/listinfo/users > <http://lists.ovirt.org/mailman/listinfo/users> > > > -- Matthias Leopold IT Systems & Communications Medizinische Universität Wien Spitalgasse 23 / BT 88 /Ebene 00 A-1090 Wien Tel: +43 1 40160-21241 Fax: +43 1 40160-921200