<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, May 25, 2017 at 12:11 PM Barak Korren &lt;<a href="mailto:bkorren@redhat.com">bkorren@redhat.com</a>&gt; 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_extra"><div class="gmail_quote">On 25 May 2017 at 11:22, Nir Soffer <span dir="ltr">&lt;<a href="mailto:nsoffer@redhat.com" target="_blank">nsoffer@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Vdsm and ovirt-imageio use /var/tmp because we need file system supporting direct I/O. /tmp is using tmpfs which does not support it. <div><br></div><div>We have no need for &quot;cached&quot; data kept after a test run, and we cannot promise that test will never leave junk in /var/tmp since tests run before they are reviewed. Even correct tests can leave junk if the test runner is killed (for example, on timeout).</div><div><br></div><div>The only way to keep slaves clean is to clean /tmp and /var/tmp after each run. Treating /var/tmp as cache is very wrong.</div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>You need to differentiate between the &#39;/var/tmp&#39; you see from your<br>scripts to the one we are talking about here.<br><br></div><div>- When you use /var/tmp in your script you use the one inside the mock<br>  environment. It is specific to yore script run time environment and <br>  will always be wiped out when its done.<br></div></div></div></div></blockquote><div><br></div><div>Great, this is what we need.</div><div> </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_extra"><div class="gmail_quote"><div><br></div><div>- We are talking about &quot;/var/tmp&quot; _of_the_execution_slave_, the only<br>  way you can get to it is either specifically bind-mount it from the <br></div><div>  &quot;*.mounts&quot; file, or have some daemon like libvirtd or dockerd write<br></div><div>  to it.<br></div></div></div></div></blockquote><div><br></div><div>In this case, I don&#39;t see how vdsm tests can pollute the host /var/tmp.</div><div><br></div><div>Vdsm run 2 tests running virt-alignment-scan, one with --help, and one</div><div>with non existing images, so the temporary directory cannot be created</div><div>by these tests.</div><div> </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_extra"><div class="gmail_quote"><div></div></div><br></div><div class="gmail_extra">BTW if you want any guarantees about the FS you are using, you better <br>bind-mount something to the point you are writing to, otherwise things <br>will break when we make infrastructure changes like for example moving <br></div><div class="gmail_extra">the chroots to RAM or onto layered file-systems.<br clear="all"></div></div></blockquote><div><br></div><div>We need a location which exists on developer laptop, developer hosts,</div><div>and CI environments, and /var/tmp proved to be a good choice so far.</div><div>We expect that ovirt CI will not break this assumption in the future.<br></div><div><br></div><div>However, writing test data to storage is a waste of time, and having</div><div>a memory based file system supporting direct I/O would speed up lot</div><div>of tests.</div><div><br></div><div>So we can do this:</div><div><br></div><div>truncate -s 5g /tmp/backing<br></div><div>mkfs.ext4 /tmp/backing<br></div><div>mount -o loop /tmp/backing /tmp/mnt<br></div><div><br></div><div>And now we have direct I/O support and great performance:</div><div><div><br></div><div>$ dd if=/dev/zero of=/tmp/mnt/direct-io-test bs=8M count=128 oflag=direct</div><div>128+0 records in</div><div>128+0 records out</div><div>1073741824 bytes (1.1 GB, 1.0 GiB) copied, 0.536528 s, 2.0 GB/s</div></div><div><br></div><div>This greatly speeds up some tests which are marked a slow tests, and </div><div>never run unless using --enable-slow-tests.</div><div><br></div><div><div>Without slow tests using /var/tmp:</div>$ ./run_tests_local.sh storage_qcow2_test.py -s<br>...<br>Ran 31 tests in 0.709s<br><br>With slow tests using loop device based temporary directory:<br>$ ./run_tests_local.sh storage_qcow2_test.py --enable-slow-tests -s<br>...<br>Ran 31 tests in 7.019s<br><br>With slow tests, using /var/tmp:<br>$ ./run_tests_local.sh storage_qcow2_test.py --enable-slow-tests -s<br>...<br>Ran 31 tests in 90.491s<br></div><div><br></div><div><br></div><div>This requires root to mounting and unmounting the backing file, so</div><div>it is not a good solution for developers, when you need to run certain</div><div>tests all the time, but it can be a good solution for the CI.</div><div><br></div><div>Barak, do you think ovirt CI can provide this functionality?</div><div><br></div><div>Nir</div></div></div>