Run the deploy job on Gimlets#10750
Conversation
| # The gimlet factory creates a zpool on /pool/bsu/0 backed by the first M.2 | ||
| # disk. We use it to store large files that wouldn't fit in the ramdisk. | ||
| SCRATCH_DIR=/pool/bsu/0/scratch | ||
| pfexec mkdir $SCRATCH_DIR |
There was a problem hiding this comment.
FWIW, there are some other jobs that use Gimlet runners that are instead using pilot local disk list to find disks to make a zpool on, like this: https://github.com/oxidecomputer/propolis/blob/979b72896bc39a876c98fb32fe706da37a4fc408/.github/buildomat/phd-run-with-args.sh#L17-L21
Do you think we ought to use that to using the scratch dataset there too? It might shave a bit off the job's total runtime if we didn't go and initialize another zpool...
| # The gimlet factory creates a zpool on /pool/bsu/0 backed by the first M.2 | ||
| # disk. We use it to store large files that wouldn't fit in the ramdisk. |
There was a problem hiding this comment.
I'm not sure what their DWPD is, but is the endurance of the M.2 drives a problem we should worry about?
There was a problem hiding this comment.
That is something we were already doing before on the other systems. In practice the only thing we are writing to the M.2s is the vdevs used to store zones on, so I'm not too worried.
b3d4279 to
11dafb2
Compare
05b8416 to
cf769f6
Compare
11dafb2 to
47e4da3
Compare
This should enable us to increase capacity on the job. I had to increase the timeouts for some of the retry loops to get the job to succeed.
Fixes #10054.
This is stacked on top of #10749.