[ovirt-users] OVirt 4.1.2 - trim/discard on HDD/XFS/NFS contraproductive
Nir Soffer
nsoffer at redhat.com
Sun Jun 18 06:29:11 UTC 2017
בתאריך יום א׳, 18 ביוני 2017, 9:01, מאת Idan Shaby <ishaby at redhat.com>:
> Hi Markus,
>
> AFAIK, mkfs.xfs tries to discard all the blocks before formatting the
> device.
> If you don't want it to do that, you can use the "-K Do not attempt to
> discard blocks at mkfs time" option of mkfs.xfs.
>
> In oVirt 4.1 we introduced the "Enable Discard" flag for a virtual
> machine's disk.
> When enabled, qemu is configured to pass on live UNMAP SCSI commands from
> the guest to the underlying storage.
> If you don't need live discarding, shutdown the VM and disable the "Enable
> Discard" option. That will cause qemu to ignore the live UNMAP SCSI
> commands coming from the guest and not pass it on to the underlying storage.
> Note that this makes fstrim completely redundant, as the purpose of the
> command is to discard unused blocks under the given path.
>
I think we need a bug for this, both fo documrnting this issue, and to
investigate why discarding unused blocks allocate and zero all blocks. This
behaviour is unhelpful.
Markus, can you check if performing the same discard from the host leads to
same result?
>
> Regards,
> Idan
>
> On Sat, Jun 17, 2017 at 1:25 AM, Markus Stockhausen <
> stockhausen at collogia.de> wrote:
>
>> Hi,
>>
>> we just set up a new 4.1.2 OVirt cluster. It is a quite normal
>> HDD/XFS/NFS stack that worked quit well with 4.0 in the past.
>> Inside the VMs we use XFS too.
>>
>> To our surprise we observe abysmal high IO during mkfs.xfs
>> and fstrim inside the VM. A simple example:
>>
>> Step 1: Create 100G Thin disk
>> Result 1: Disk occupies ~10M on storage
>>
>> Step 2: Format disk inside VM with mkfs.xfs
>> Result 2: Disk occupies 100G on storage
>>
>> Changing the discard flag on the disk does not have any effect.
>>
>> Am I missing something?
>>
>> Best regards.
>>
>> Markus
>>
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
> _______________________________________________
> 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/20170618/9a6bdb04/attachment.html>
More information about the Users
mailing list