Do we have a protocol/action plan for what to do following the 'no space left on device' issue (issue #113)

[Alfredo-Enrique]

Hi team! I have 5 tumour normal pairs which get the 'no space left on device' issue from closed #113. Based on that issue it says to just run on a node with 3T scratch space. I'm guessing there's a non-standard node to do this with?

How do we go about launching such jobs?

---

Side note, we should probably get the metrics (read count, depth, file size, etc...) from such samples (and from #113's) so we have an idea of at which read count / file size we start needing the larger scratch space.

[yashpatel6]

Hi team! I have 5 tumour normal pairs which get the 'no space left on device' issue from closed #113. Based on that issue it says to just run on a node with 3T scratch space. I'm guessing there's a non-standard node to do this with?

In addition to using a larger scratch disk, the pipeline also has the gatk_ir_compression parameter. The default is 0 (lowest compression but fastest) but this can be increased to increased compression (and reduce disk usage) at the cost of some speed.

How do we go about launching such jobs?

The 3TB has limited access at the moment so you'd need to get someone with access (currently, me, Taka, Trevor, Aaron, Mao) to launch the job.

Side note, we should probably get the metrics (read count, depth, file size, etc...) from such samples (and from #113's) so we have an idea of at which read count / file size we start needing the larger scratch space.

This is something we have planned; basically benchmarking the disk usage with different parameters and different samples.