Same deal as bug 1271035. It's happening in WPT tests too. From https://treeherder.mozilla.org/#/jobs?repo=try&revision=e276fe78829f161605f6e361090e001999cab152 Bytes Written Linux64 Opt W1 1,745,862,656 Linux64 Opt W3 1,115,738,112 Linux64 Opt W4 1,557,487,616 Linux64 Opt W5 1,065,558,016 OS X 10.10 Opt W1 1,960,006,144 OS X 10.10 Opt W3 1,448,801,792 OS X 10.10 Opt W4 1,802,521,600 OS X 10.10 Opt W5 1,257,460,736 This is *system* bytes during the entire job. A few hundred MB will be e.g. extracting the binary and test archive. And, not all I/O incurred by SQLite hits the system (a lot gets serviced by the page cache). From local running with procmon, Places seems to be the source of most of the I/O during test execution however. The magnitude of the problem appears smaller, but it's definitely there. I know WPT tests are a bit higher level than reftests. And I /think/ there are e.g. DOM features that may rely on Places working to pass. What I don't know is if WPT tests any of those. Ms2ger: What are the concerns with disabling Places when running WPT? If some tests require Places, could we somehow annotate tests that require Places and enable Places only for those?

I presume that tests requiring e.g. history.back will not work without places enabled. So just disabling it isn't going to work. Working out where it's safe to disable now is straightforward; we do a try run with it disabled and see where tests fail. The more challenging problem is keeping that information correct as we sync from upstream.

(In reply to James Graham [:jgraham] from comment #1) > I presume that tests requiring e.g. history.back will not work without > places enabled. session history is different from global history and doesn't depend on Places. It should work.

Try seems to agree with you: https://treeherder.mozilla.org/#/jobs?repo=try&revision=c440a24a48ee&selectedJob=20553768 I'll do a bigger try run to check there isn't any platform-specific weirdness, but otherwise this looks good. (if we think this is the right default for testsuites, it might make sense to edit prefs_general.js to set this pref, and then unset it for test[suites] where it is not wanted).

This landed as part of Bug 1273176