<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 29, 2018 at 5:19 PM Nir Soffer <<a href="mailto:nirsof@gmail.com">nirsof@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Mar 29, 2018 at 1:59 PM Richard W.M. Jones <<a href="mailto:rjones@redhat.com" target="_blank">rjones@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I found another problem which is sort of related to this thread. I<br>
hit a time-out waiting for the disk to be unlocked after creation:<br>
<br>
<a href="https://github.com/libguestfs/libguestfs/commit/8081f54105bd990233f166170890192c1fd7d1f3#diff-5ca47c29ae13efa3959b8b28cf4dbd31R112" rel="noreferrer" target="_blank">https://github.com/libguestfs/libguestfs/commit/8081f54105bd990233f166170890192c1fd7d1f3#diff-5ca47c29ae13efa3959b8b28cf4dbd31R112</a><br>
line 112<br>
<br>
The disk size in this case is 40 GB and we currently wait 5 minutes.<br>
<br>
On the ovirt-node there's an ‘fallocate’ process (still) running.<br>
It's taken 23 minutes so far.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>This code is using posix_fallocate and it can be very slow on NFS < 4.2,</div><div>writing one byte to every 4k block.</div></div></div></blockquote><div><br></div><div>Actually it is worse - today we:</div><div><br></div><div>1. create virtual_size bytes volume</div><div>2. preallocate entire image using posix_fallocate, possibly writing </div><div> one byte to every 4k sector</div><div>3. write virtual_size bytes of data to volume</div><div class="gmail_quote"><br></div>The preallocation is mostly useless. It can save you time if there</div><div class="gmail_quote">is not enough storage to copy the volume, but you have to pay for</div><div class="gmail_quote">something that practically never happen for every volume you create.<br class="inbox-inbox-Apple-interchange-newline"><div><br></div><div>I have this patch:</div><div><a href="https://gerrit.ovirt.org/#/c/86282/">https://gerrit.ovirt.org/#/c/86282/</a><br></div><div><br></div><div>With this you will be able to create a raw preallocated</div><div>volume without preallocating anything using initial_size=0,</div><div>avoiding the slow creation you experience now.</div><div><br></div><div>The file will be allocated by uploading the data into the volume.</div><div><br></div><div>This will require also changes on engine side, currently we don't </div><div>send initial_size to vdsm for file storage.</div><div><br></div><div>It would be nice if you file a performance bug for this issue.</div><div><br></div><div>Nir</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Because we didn't reach a satisfactory conclusion of the whole<br>
sparse/format business, I am currently setting sparse = False<br>
(format is always raw in my testing):<br>
<br>
<a href="https://github.com/libguestfs/libguestfs/commit/8081f54105bd990233f166170890192c1fd7d1f3#diff-5ca47c29ae13efa3959b8b28cf4dbd31R92" rel="noreferrer" target="_blank">https://github.com/libguestfs/libguestfs/commit/8081f54105bd990233f166170890192c1fd7d1f3#diff-5ca47c29ae13efa3959b8b28cf4dbd31R92</a><br>
line 92<br>
<br>
I guess this is the cause of this problem in some sense. Is there<br>
something we can do? I'm still unclear how to fix the sparse/format<br>
mess, it seems unsolvable from the client side because we don't have<br>
sufficient information to make a decision.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>I don't think always using sparse=False is a good solution. We have an issue</div><div>only with block storage, so there is no need to force sparse=False for every</div><div>kind of storage.</div><div><br></div><div>I think the behavior should be:</div><div><br></div><div>- if the user wants raw image (sparse=False) on file domain we can warn that </div><div>creating preallocated disk on file storage can take lot of time, and we should</div><div>wait until the disk is ready. Or we can always use thin for upload to file based</div><div>storage, this is what we for uploading from the UI.</div><div><br></div><div>- if the user wants thin image on block storage, we must allocate the entire</div><div>image when we create a disk. In 4.2.4 we will support engine API to reduce</div><div>an image to the optimal size, and you will be able to call this when you complete</div><div>the upload.</div><div><br></div><div>- if the user wants thin image on file storage, or raw image on block storage,</div><div>we don't have any issue</div><div><br></div><div>In 4.3 we plan to improve engine extend volume api so it will update the ticket</div><div>size when extending a disk. With this you will be able to create a thin disk on</div><div>block storage and extend it when needed.</div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Nir</div></div></div></blockquote></div></div>