test,flake: async-hooks/test-fseventwrap flaky on Travis

[refack]

• Version: master
• Platform: Travis
• Subsystem: test,async-hooks,fs

https://travis-ci.com/nodejs/node/jobs/128751722#L9568

not ok 17 async-hooks/test-fseventwrap
  ---
  duration_ms: 0.135
  severity: fail
  exitcode: 1
  stack: |-
    internal/fs/watchers.js:155
        throw error;
        ^
    
    Error: ENOSPC: no space left on device, watch '/home/travis/build/nodejs/node/test/async-hooks/test-fseventwrap.js'
        at FSWatcher.start (internal/fs/watchers.js:149:26)
        at Object.watch (fs.js:1234:11)
        at Object.<anonymous> (/home/travis/build/nodejs/node/test/async-hooks/test-fseventwrap.js:16:20)
        at Module._compile (internal/modules/cjs/loader.js:702:30)
        at Object.Module._extensions..js (internal/modules/cjs/loader.js:713:10)
        at Module.load (internal/modules/cjs/loader.js:612:32)
        at tryModuleLoad (internal/modules/cjs/loader.js:551:12)
        at Function.Module._load (internal/modules/cjs/loader.js:543:3)
        at Function.Module.runMain (internal/modules/cjs/loader.js:744:10)
        at startup (internal/bootstrap/node.js:267:19)
  ...

[apapirovski]

I mean, is it flaky if the device is out of space?

[mmarchini]

And here I was thinking Travis would give us a stable infrastructure for lightweight test runs ¯_(ツ)_/¯

[mmarchini]

I mean, is it flaky if the device is out of space?

I think so, since this will result in failures on PRs. But are there any actions we can take to avoid this?

[refack]

I mean, is it flaky if the device is out of space?

If the test does not run reliably and gives intermittent false negatives IMHO that's the definition of flaky.
Also, it's hard to say if ENOSPC this is the real error since it happened only at the beginning of the suite, and ~2000 test run after that.

Anyway this issue is here so that peeps seeing this can cross reference.

[mscdex]

According to Travis' documentation there should be about ~9GB of disk space available for the configuration we're currently using. If we instead used a VM (sudo: required and dist: trusty) we could double the amount of available memory and disk space, if disk space is what is the issue here.

Has anyone tried to rerun an instance with debug mode enabled so you can ssh in and verify disk space availability?