<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">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>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 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>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><br></div><div>Nir</div></div></div>