[Windows] C drive is siginificant slower than D drive which causes issue with workflow runtime being significantly increased in general

[jetersen]

Description

This seems to affect all Windows based hosted runners.
In general tool installation, download speeds and compression and decompression on anything that is on the C drive as in any IO is significantly slower compared to D drive.

Somewhat based on research in #3577 and actions/setup-dotnet#260

Seems like actions/setup-go seems to have made a workaround for actions/setup-go#393

There is a suggestion to make similar workarounds in the actions/setup-dotnet actions/setup-dotnet#260 (comment)

Hopefully we can find a solution that is more generic for all 😅
Maybe we can simply make the C drive similar to the D drive? That way there is no difference.
I assume this is most likely a small change in the packer script?

Platforms affected

• Azure DevOps
• GitHub Actions - Standard Runners
• GitHub Actions - Larger Runners

Runner images affected

• Ubuntu 20.04
• Ubuntu 22.04
• macOS 11
• macOS 12
• macOS 13
• Windows Server 2019
• Windows Server 2022

Image version and build link

https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736383956/job/18311632176
https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736262624

Is it regression?

Yes/No it has been a constant regression

Expected behavior

Windows actions should be similar or only a few seconds slower not like 30 seconds more.

Actual behavior

Depending on IO everything is significantly slower sometimes a whole minute slower or longer depending on how much IO.

Repro steps

https://github.com/jetersen/dotnet.restore.slow.github.action

[shamil-mubarakshin]

Hello @jetersen,
We will have a look

[Piedone]

As far as I understand, this would need a change of $GITHUB_WORKSPACE at its core. Then, actions/checkout would be able to use the D drive too.

[jetersen]

I don't like the solution to just move everything to the D drive 😅
It means changes throughout many actions and something all actions developers have to be aware of.

I would hope the solution was to make C drive have the same iOPS, throughput and disk technology (Premium SSD, Standard SSD, Standard HDD in azure terms) as the D drive

[shamil-mubarakshin]

@jetersen, unfortunately, there is no simple fix to put C drive's performance on par with D drive.
There are certain limitations that we don't expect to be solved in the near future.
I will close the issue for now. Feel free to reach out to us in case of further concerns.

[PureKrome]

@shamil-mubarakshin 👋🏻 G'Day. I'm not sure I quite understand the solution here?

So changing the "C" drive's hardware isn't going to happen right now / short-term, etc. Fine. .. but surely there's still some possibility of doing some of the actions, running on the "D" drive, right?

or even making some approved actions that work on "D" allowing people to "opt-in" to this (for backwards compat)?