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. 
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.
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@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@redhat.com> wrote:

On Wed, May 24, 2017 at 12:38 PM, Yaniv Kaul <ykaul@redhat.com> wrote:


On Wed, May 24, 2017 at 11:35 AM, Barak Korren <bkorren@redhat.com> wrote:
On 24 May 2017 at 11:17, Yaniv Kaul <ykaul@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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel

_______________________________________________
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel