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.
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(a)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(a)redhat.com> wrote:
On Wed, May 24, 2017 at 12:38 PM, Yaniv Kaul <ykaul(a)redhat.com> wrote:
>
>
> On Wed, May 24, 2017 at 11:35 AM, Barak Korren <bkorren(a)redhat.com>
> wrote:
>
>> On 24 May 2017 at 11:17, Yaniv Kaul <ykaul(a)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(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/devel
>
_______________________________________________
Devel mailing list
Devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel