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

Idan Shaby ishaby at redhat.com
Sun Feb 11 07:55:47 UTC 2018


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/storage/pass-discard-from-guest-to-underlying-storage/

On Thu, Feb 8, 2018 at 2:08 PM, Matthias Leopold <
matthias.leopold at meduniwien.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
> http://lists.ovirt.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20180211/2eb2f541/attachment.html>


More information about the Users mailing list