[igt-dev] [PATCH i-g-t 2/2] runner: Introduce --disk-usage-limit

[Petri Latvala]

On Thu, Jun 18, 2020 at 03:26:28PM +0300, Arkadiusz Hiler wrote:
> On Thu, Jun 18, 2020 at 03:06:23PM +0300, Petri Latvala wrote:
> > Disk usage limit is a limit of disk space taken, per (dynamic)
> > subtest. If the test's output, kernel log included, exceeds this
> > limit, the test is killed, similarly to killing the test when the
> > kernel gets tainted.
> 
> So this is a combined limit, i.e. shared by stderr, stdout and dmesg,
> right?

Yes, combined limit.

> Also since this is handled by need_to_timeout, will the final test
> result be a timeout?

It will be an incomplete. With an injection in the stdout, like when
killing for taints, for automatic filtering.

> Any particular reason why we are killing the test instead of just
> appending a message that output was truncated and letting the test be?
> 
> When we were talking about this I had imagined something more like:
> 
>  1. size limit per logged file
>  2. test finishes execution
>  3. the logs state that the test was spammy and we truncated the logs
>  4. "promote" passes to warns in such cases
> 
> No strong feeling on which option we will go with, but I would like to
> understand why you went in that way.

In my opinion it's a waste of disk space on the DUT; There shouldn't
be a case where having "too much" (tm) stuff logged is considered
normal. And if we accept that, we might as well also save some time by
killing the test when we go over.

Truncating the logs is possible but way more code; Instead of just
finding the delimit offsets in the stdout file and stuffing that range
to the json string object, you need to construct a new string, making
sure you avoid cutting out the subtest result line. I repeat:
Possible, almost easy. Just more code in an already complex resultgen
codebase for doing a simple thing :P

So in a nutshell: The approach depends on whether spamming logs is
considered "just a warn" or "oh, please no".


-- 
Petri Latvala