<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 12, 2016 at 10:45 PM, Markus Stockhausen <span dir="ltr"><<a href="mailto:stockhausen@collogia.de" target="_blank">stockhausen@collogia.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">>> Von: Yaniv Kaul [<a href="mailto:ykaul@redhat.com">ykaul@redhat.com</a>]<br>
>> Gesendet: Dienstag, 12. Januar 2016 13:15<br>
<span class="">>> An: Markus Stockhausen<br>
>> Cc: <a href="mailto:users@ovirt.org">users@ovirt.org</a>; Mike Hildebrandt<br>
>> Betreff: Re: [ovirt-users] NFS IO timeout configuration<br>
>><br>
</span><span class="">>> On Tue, Jan 12, 2016 at 9:32 AM, Markus Stockhausen <a href="mailto:stockhausen@collogia.de">stockhausen@collogia.de</a>> wrote:<br>
>> Hi there,<br>
>><br>
>> we got a nasty situation yesterday in our OVirt 3.5.6 environment.<br>
>> We ran a LSM that failed during the cleanup operation. To be precise<br>
>> when the process deleted an image on the source NFS storage.<br>
><br>
> Can you share with us your NFS server details?<br>
>Is the NFS connection healthy (can be seen with nfsstat)<br>
>Generally, delete on NFS should be a pretty quick operation.<br>
> Y.<br>
<br>
</span>Hi Yaniv,<br>
<br>
we usually have no problems with our NFS server. From our observations we<br>
only have issues when deleting files with many extents. This applies to all<br>
OVirt images files. Several of them have more than 50.000 extents, a few<br>
even more than 300.000.<br>
<br>
> xfs_bmap 1cb5906f-65d8-4174-99b1-74f5b3cbc537<br>
...<br>
52976: [629122144..629130335]: 10986198592..10986206783<br>
52977: [629130336..629130343]: 10986403456..10986403463<br>
52978: [629130344..629138535]: 10986206792..10986214983<br>
52979: [629138536..629138543]: 10986411656..10986411663<br>
52980: [629138544..629145471]: 10986214992..10986221919<br>
52981: [629145472..629145575]: 10809903560..10809903663<br>
52982: [629145576..629145599]: 10737615056..10737615079<br>
<br>
Our XFS is mounted with:<br>
<br>
/dev/mapper/vg00-lvdata on /var/nas4 type xfs (rw,noatime,nodiratime,allocsize=16m)<br>
<br>
Why we use allocsize=16M? We once started with allocize=512MB. This<br>
led to sparse files that did not save much bytes. Because a single byte written<br>
resulted in a 512MB allocation. Thin allocation of these files resulted in long runtimes<br>
for formatting disks inside the VMS. So we reduced to 16MB as a balanced config<br>
<br>
This works quite well but not for remove operations.<br>
<br>
Better ideas?<br></blockquote><div><br></div><div>Sounds like an XFS issue more than NFS.</div><div>I've consulted with one of our XFS gurus - here's his reply:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">For vm image files, users should set up extent size hints to define<br>the minimum extent allocation size in a file - allocsize does<br>nothing for random writes into sparse files. I typically use a hint<br>of 1MB for all my vm images....`<br></blockquote><div><br></div><div>Y.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><font color="#888888"><br>
Markus<br>
<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>