------=_NextPartTM-000-9c273f1c-a2dd-4aba-ab90-4aa24b5ef225 Content-Type: multipart/alternative; boundary="_000_12EF8D94C6F8734FB2FF37B9FBEDD173010E01F85CEXCHANGEcollo_" --_000_12EF8D94C6F8734FB2FF37B9FBEDD173010E01F85CEXCHANGEcollo_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Von: Yaniv Kaul [ykaul@redhat.com] Gesendet: Sonntag, 18. Juni 2017 09:58 An: Markus Stockhausen Cc: Ovirt Users Betreff: Re: [ovirt-users] OVirt 4.1.2 - trim/discard on HDD/XFS/NFS cont= raproductive
On Sat, Jun 17, 2017 at 1:25 AM, Markus Stockhausen <stockhausen@collogia.d= e<mailto:stockhausen@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.
Are you sure it's discarding, at all? 1. NFS: only NFSv4.2 supports discard. Is that the case in your setup? 2. What's the value of /sys/block/<disk>/queue/discard_granularity ? 3. Can you share the mkfs.xfs command line? 4. Are you sure it's not a raw-sparse image?
Questions should answered in BZ1462504. When talking about thin provisioned disks I'm only referring to the OVirt disk-option. So I might mix up something here. Nevertheless the following is more than strange for me: - Create disk image: File on storage is small - Format inside VM: File on storage is fully allocated - Move around in Ovirt to another NFS storage: File is small again. That means: - mkfs.xfs inside VM and so qemu is hammering (empty) data into all blocks - But this data must be zeros as they can be compated afterwards. Best regards. Markus --_000_12EF8D94C6F8734FB2FF37B9FBEDD173010E01F85CEXCHANGEcollo_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <html dir=3D"ltr"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> <style type=3D"text/css" id=3D"owaParaStyle"></style> </head> <body fpstyle=3D"1" ocsi=3D"0"> <div style=3D"direction: ltr;font-family: Arial;color: #000000;font-size: 1= 0pt;"> <div style=3D"font-family: Times New Roman; color: #000000; font-size: 16px= "> <div id=3D"divRpF331137" style=3D"direction: ltr;"><font face=3D"Tahoma" si= ze=3D"2" color=3D"#000000"><b>> Von:</b> Yaniv Kaul [ykaul@redhat.com]<b= r> <b>> Gesendet:</b> Sonntag, 18. Juni 2017 09:58<br> <b>> An:</b> Markus Stockhausen<br> <b>> Cc:</b> Ovirt Users<br> <b>> Betreff:</b> Re: [ovirt-users] OVirt 4.1.2 - trim/discard on HDD/XF= S/NFS contraproductive<br> </font></div> <div id=3D"divRpF331137" style=3D"direction: ltr;"><font face=3D"Tahoma" si= ze=3D"2" color=3D"#000000"><br> </font></div> <div> <div dir=3D"ltr"> <div class=3D"gmail_extra"> <div class=3D"gmail_quote">On Sat, Jun 17, 2017 at 1:25 AM, Markus Stockhau= sen <span dir=3D"ltr"> <<a href=3D"mailto:stockhausen@collogia.de" target=3D"_blank">stockhause= n@collogia.de</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; border= -left:1px solid rgb(204,204,204); padding-left:1ex"> <div> <div style=3D"direction:ltr; font-family:Arial; color:rgb(0,0,0); font-size= :10pt"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div style=3D"font-family:Tahoma; font-size:13px"> <div> <div>Hi, </div> <div><br> </div> <div>we just set up a new 4.1.2 OVirt cluster. It is a quite normal</div> <div>HDD/XFS/NFS stack that worked quit well with 4.0 in the past. </d= iv> <div>Inside the VMs we use XFS too.</div> <div><br> </div> <div>To our surprise we observe abysmal high IO during mkfs.xfs </div> <div>and fstrim inside the VM. A simple example:</div> <div><br> </div> <div>Step 1: Create 100G Thin disk</div> <div>Result 1: Disk occupies ~10M on storage</div> <div><br> </div> <div>Step 2: Format disk inside VM with mkfs.xfs</div> <div>Result 2: Disk occupies 100G on storage</div> <div><br> </div> <div>Changing the discard flag on the disk does not have any effect.</div> </div> </div> </div> </div> </div> </div> </div> </div> </blockquote> <div><br> </div> <div>> Are you sure it's discarding, at all?</div> <div>> 1. NFS: only NFSv4.2 supports discard. Is that the case in your s= etup?</div> <div>> 2. What's the value of /sys/block/<disk>/queue/discard= _granularity ?</div> <div>> 3. Can you share the mkfs.xfs command line?</div> <div>> 4. Are you sure it's not a raw-sparse image?</div> <div><br> </div> <div>Questions should answered in BZ1462504. When talking about thin</div> <div>provisioned disks I'm only referring to the OVirt disk-option. So I</d= iv> <div>might mix up something here. Nevertheless the following is more than</= div> <div>strange for me:</div> <div><br> </div> <div>- Create disk image: File on storage is small</div> <div>- Format inside VM: File on storage is fully allocated </div> <div>- Move around in Ovirt to another NFS storage: File is small again. </= div> <div><br> </div> <div>That means:</div> <div>- mkfs.xfs inside VM and so qemu is hammering (empty) data into all bl= ocks</div> <div>- But this data must be zeros as they can be compated afterwards.</div=
<div><br> </div> <div>Best regards.</div> <div><br> </div> <div>Markus</div> <div><br> </div> </div> </div> </div> </div> </div> </div> </body> </html> --_000_12EF8D94C6F8734FB2FF37B9FBEDD173010E01F85CEXCHANGEcollo_-- ------=_NextPartTM-000-9c273f1c-a2dd-4aba-ab90-4aa24b5ef225 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" **************************************************************************** Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. Über das Internet versandte E-Mails können unter fremden Namen erstellt oder manipuliert werden. Deshalb ist diese als E-Mail verschickte Nachricht keine rechtsverbindliche Willenserklärung. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln Vorstand: Kadir Akin Dr. Michael Höhnerbach Vorsitzender des Aufsichtsrates: Hans Kristian Langva Registergericht: Amtsgericht Köln Registernummer: HRB 52 497 This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. e-mails sent over the internet may have been written under a wrong name or been manipulated. That is why this message sent as an e-mail is not a legally binding declaration of intention. Collogia Unternehmensberatung AG Ubierring 11 D-50678 Köln executive board: Kadir Akin Dr. Michael Höhnerbach President of the supervisory board: Hans Kristian Langva Registry office: district court Cologne Register number: HRB 52 497 **************************************************************************** ------=_NextPartTM-000-9c273f1c-a2dd-4aba-ab90-4aa24b5ef225--