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

[Arkadiusz Hiler]

On Thu, Jun 18, 2020 at 03:49:07PM +0300, Petri Latvala wrote:
> 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".

I'll take one "oh, please no".

Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler at intel.com>