[ovirt-devel] ovirt-imageio leaves .guestfs-0 folder under /var/tmp during check-patch

[Nir Soffer]

בתאריך יום ה׳, 25 במאי 2017, 10:59, מאת Gil Shinar ‏<gshinar at redhat.com>:

> I wrote that it was imageio because I have disabled deletion of /var/tmp
> on one job only (jenkins check-patch) and saw that on the same Jenkins
> slave only imageio check-patch and Jenkins check-patch run. Jenkins
> check-patch has nothing to do with libguestfs so I assumed that imageio did.
> Here is a list of running jobs on the slave I have checked /var/tmp on.
> The imageio job cleans /var/tmp and jenkins job doesn't.
> [image: Inline image 1]
>
> Anyhow, I'll take your word on that and assume that the Jenkins build
> history has bugs and a VDSM or some other job run on that slave.
>
> Now lets go back to the main interest of this thread. If we'll know, that
> whatever is being written to /var/tmp, can be considered as cache and can
> be used by the next run of the job that uses it, it might be a good idea
> not to clean /var/tmp. Jenkins is helping us with that by trying to run
> jobs on the same slave as much as possible.
>

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.

We have no need for "cached" 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).

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.

We will start by monitoring our disks constantly to see how fast, if at
> all, they are getting full.
>
> On Wed, May 24, 2017 at 6:28 PM, Michal Skrivanek <mskrivan at redhat.com>
> wrote:
>
>> To get back to the original point - I do not see a connection with
>> imageio anywhere. It's libguestfs's temp dir. Now to decide what to do with
>> it I think we should first understand which test uses/invokes libguestfs
>> and for what purpose?
>>
>> On 24 May 2017, at 12:35, Gil Shinar <gshinar at redhat.com> wrote:
>>
>> On Wed, May 24, 2017 at 12:38 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
>>
>>>
>>>
>>> On Wed, May 24, 2017 at 11:35 AM, Barak Korren <bkorren at redhat.com>
>>> wrote:
>>>
>>>> On 24 May 2017 at 11:17, Yaniv Kaul <ykaul at redhat.com> wrote:
>>>> >
>>>> > /dev/shm is just as good. It's only 400MB.
>>>> > Y.
>>>> >
>>>> Forgive my language but, hell no.  This is not the gigantic Lago
>>>> bare metals you are used to. We don't want GWT builds to start
>>>> failing on running out of RAM.
>>>>
>>>
>>> Buy more RAM.
>>>
>>
>> This is the best solution as having the cache on the ram will shorten the
>> time of engine jobs.
>>
>>> Y.
>>>
>>>
>>>>
>>>> --
>>>> Barak Korren
>>>> RHV DevOps team , RHCE, RHCi
>>>> Red Hat EMEA
>>>> redhat.com | TRIED. TESTED. TRUSTED. | redhat.com/trusted
>>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/devel
>>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170525/9d2076eb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 53683 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170525/9d2076eb/attachment-0001.png>