[OE-core] [PATCH 2/3] rm_work_and_downloads.bbclass: more aggressively minimize disk usage

[Randy Witt]

On Fri, Jan 6, 2017 at 11:22 AM, Patrick Ohly <patrick.ohly at intel.com>
wrote:

> On Fri, 2017-01-06 at 10:31 -0800, Randy Witt wrote:
>
> >
> > I'd rather see this be a new class independent from rm_work. People
> > can always in inherit both rm_work and rm_download.
>
> I'm not sure whether it's worth supporting that mode: what would be the
> motivation for removing downloads, but not the work directory?
>
>
There are times that the work directories help with the debugging of build
failures. The logs aren't always enough. So a person might want to do
something like remove the downloads, but preserve the actual work,
especially in the case of failures.

I'll admit it is a fabricated scenario, but in general I'm against one knob
requiring the turning of another knob.


> The motivation for rm_work_and_downloads.bbclass is the same as for
> rm_work.bbclass: reducing the required disk space *during* the build, to
> get builds to succeed which otherwise would run out of disk space.
>
>
Disk space isn't the only motivation for rm_work. It also allows for
deletion of large amounts of inodes before they've been flushed to disk. So
rather than taking minutes worth of time to clean up post build, and
thrashing media that other tasks may be using, it is almost instantaneous
because everything is still in the page cache.

Also the build itself can be faster for the same reason, there is no
waiting for data to be flushed out to disk( because it was deleted while
still in the page cache) and thus impacting reads in other parts of the
build.


> A "rm -rf downloads" at the end of the build doesn't help achieve that
> goal.
>
>
That's true, I hadn't yet processed it completely. Ignore that comment. :)

As an overall comment though, I really like the idea of rm_work not being
deferred for so long. It always seemed strange to me to see the thundering
herd of rm_works after certain do_builds would finish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20170106/832662e4/attachment-0002.html>