[ovirt-users] effectiveness of "discard=unmap"

[Idan Shaby]

On Mon, Feb 12, 2018 at 1:55 PM, Matthias Leopold <
matthias.leopold at meduniwien.ac.at> wrote:

> 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".
>
The file /sys/block/dm-X/queue/discard_max_bytes in sysfs tells you whether
your underlying storage supports discard.
The flag discard=unmap of the VM in qemu means that qemu will not throw
away the UNMAP commands comming from the guest OS (by default it does throw
them away).
>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 at meduniwien.ac.at <mailto:matthias.leopold at 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 at ovirt.org <mailto:Users at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180212/28787b97/attachment.html>