Please increase the maximum allowed workspace size to 50GB

[jankeromnes]

Feature request: Please bump the maximum allowed workspace size from 30GB to 50GB.

I've put a lot of thought into this number, and I believe this is the right trade-off. 50GB would enable a few very cool projects to work on Gitpod (e.g. Unreal Engine, LibreOffice, etc. there is a whole class of those that used to work on Gitpod but we currently block with our 30GB limit). It would also not have any downsides.

Some data: In 2020, there was a time when we didn't limit workspace size at all (so every workspace could grow arbitrarily large, and we would still do the backup). During that time, we found that (internal):

• The average workspace size [was] 405.46 MB
• 99.92% of all workspaces [were] < 20 GB
• 99.95% < 30 GB
• 99.97% < 50 GB
• 99.99% < 80 GB

So, allowing workspaces to grow arbitrarily large doesn't lead to a big average workspace size.

Also, from recent ops experience, every time we've had an alert about problematic workspaces filling up a server disk, it was always because of just a few workspaces that had grown above 100GB(!) Limiting every workspace to 50GB still prevents workspaces from reaching these alarming levels.

[purkhusid]

This is also required for organizations that have big monorepos. In my case we have a single monorepo that is built using Bazel and the build has a lot of outputs and I'm currently hitting the 30gb limit.

I would love for this change to go through so that I can continue using Gitpod in our monorepo.

[ghost]

I think that if the dead space that is allocated has to be paid for by Gitpod, that it makes more sense that the default limit be lowered down to 15 GB which would be more than enough for most projects and then add the following features for projects that require higher space allocation:

• Show how much disk space is left per workspace in the dashboard
• Option to increase/upgrade disk space if the user sees that a workspace is getting close to the default 15 GB limit
• ?size=50 parameter option to set amount of disk space in GB in the start URL https://gitpod.io/#GIT_URL

This would allow Gitpod to easily increase the default free limit later down the road if they see the need for it or even have a per plan limit, without creating/dealing with a bunch of dead allocated space that is not being used. It would also allow for there to be a paid option added to have access to an even higher disk space then 50 GB if the user needs that as well in addition to the plan that they are already paying for. Say x EUR amount for access to use 80 GB for their workspaces.

[GiancarlosIO]

🙏🏼

[purkhusid]

@jankeromnes Are there any plans to increase the size or request a bigger disk for a specific project?

[jankeromnes]

Great question @purkhusid. I'm aware of internal discussions regarding the ability to get "bigger workspaces", but I think until now this is only for CPU (e.g. see #7487).

Deferring to @gitpod-io/engineering-workspace / @atduarte regarding any plans to increase workspace disk size or making it configurable.

[csweichel]

The plans outlined in #7487 indeed refer to CPU only at this point. Considering that the larger workspaces would be available to paying customers, it's not obvious if increasing the disk size for those workspaces would actually solve a problem.

[purkhusid]

My team is currently on the Professional plan and I'm already enconoutering the 30gb limit in our monorepo. Would it be possible to have bigger disk for those on paying plans?

[purkhusid]

Would it not be possible to increase the size to 50gb while a more configurable solution is being worked on? @jankeromnes
I've been enjoying using Gitpod for our monorepo but as the repo gets bigger it gets closer and closer to being unusable.

[mikearnaldi]

We are also hitting the limit frequently, while this has been a good driver to justify a bit of refactoring and cleanup on our repos there are some where I can't get around the limit. Would be extremely helpful if we could have a config to setup the disk size, we'd be also more then fine on having such workspaces more ephemeral in the sense that you could literally trash the workspace as soon as it is stopped and claim back the disk.

Overall I have been having an amazing experience with Gitpod so far!

[kylos101]

Hi 👋 , it seems we need to do a bit of experimentation for workspace storage, to better understand current limits, but also explore impacts when they are stretched.

To that end, we've scheduled this issue and will start it this week, which'll help inform us for next steps.

[kennysong]

This would be useful for my team since our Docker images are quite large, and builds suddenly start failing because of disk space issues after a few builds / tests.

[atduarte]

Marked as blocked, as this depends on the completion of #8671.

[wimax-grapl]

^ 8671 has been closed out as no longer relevant; how does PVCs tie into this request now?

[sagor999]

PVCs are part of this epic: #7901
Initial implementation doesn't explicitly target variable workspace sizes, but with support of PVCs it will be much easier to provide such flexibility.

[darach]

We are hitting size limits frequently with tremor so an option to use/configure higher sizes would be great. A ( paid ) team plan that could allocate size limits by contributor would be of interest to us for sure!

[sagor999]

@darach Unleashed plan already offers 50GB workspace size. You might want to try that.

[sagor999]

Closing this, since Unleashed offers increased workspace size, and as of right now we don't have plans to offer increased size for other tiers.

[purkhusid]

@sagor999 Has this been discontinued in Unleashed? I just started a workspace and the size has gone down to 30gb

[sagor999]

I believe so. @atduarte for clarification.

[purkhusid]

Any specific reason for that? This feels like a regression since repos that could be built with the 50gb workspaces can no longer be built.

[atduarte]

@purkhusid I'm sorry we broke your workspaces.

50GB storage limit was part of an experiment in which we offered every Unleashed users far more resources than usual (i.e. the XL clusters, with more CPU, RAM and storage). As the experiment ended, it was not sustainable for us to keep providing these resources for free to everyone.

We are working to introduce different workspace sizes, with clearly defined guarantees, #8261 along with usage-based pricing #9036 very soon to mitigate this issue.

I will look for ways with the team on how to exceptionally mitigate your problem in the meantime, and will let you know. 🙏