Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

graphDB refuses upload when disk space is under 5% free #149

Open
surchs opened this issue Jan 8, 2024 · 2 comments
Open

graphDB refuses upload when disk space is under 5% free #149

surchs opened this issue Jan 8, 2024 · 2 comments
Labels
flag:discuss Flag issue that needs to be discussed before it can be implemented.

Comments

@surchs
Copy link
Contributor

surchs commented Jan 8, 2024

Eric just ran into this issue while following step https://neurobagel.org/infrastructure/#uploading-example-neurobagel-data.

Insufficient disk space to start a transaction for repository 'my_db' due to:
The repository 'my_db' is critically low on free disk space with 4.0% (141.82 GB) free left

graphDB by default has low disk space protections (reasonable) based on percentages (reasonable?): https://graphdb.ontotext.com/documentation/10.4/low-disk-space-health-checks.html

their absolute minimal requirement is 5% free disk.

I am not completely clear if docker volumes allow us to

  1. Set the size of the volume
  2. Hide from the container the percentage of free disk space on the host

Would be worth investigating: https://docs.docker.com/storage/ (maybe) and then update the docs / default config. If we cannot find a solution, then we should update the docs to say: this can happen if you have a single super big disk that is almost full 🤷

@surchs surchs added this to Neurobagel Jan 8, 2024
Copy link

We want to keep our issues up to date and active. This issue hasn't seen any activity in the last 75 days.
We have applied the _flag:stale label to indicate that this issue should be reviewed again.
When you review, please reread the spec and then apply one of these three options:

  • prioritize: apply the flag:schedule label to suggest moving this issue into the backlog now
  • close: if the issue is no longer relevant, explain why (give others a chance to reply) and then close.
  • archive: sometimes an issue has important information or ideas but we won't work on it soon. In this case
    apply the someday label to show that this won't be prioritized. The stalebot will ignore issues with this
    label in the future. Use sparingly!

@github-actions github-actions bot added the _flag:stale [BOT ONLY] Flag issue that hasn't been updated in a while and needs to be triaged again label Mar 24, 2024
@BobLamarley
Copy link

Hello,
I'm on mac and i have the same problem,
Did you find a solution ?
Image

@github-actions github-actions bot removed the _flag:stale [BOT ONLY] Flag issue that hasn't been updated in a while and needs to be triaged again label Oct 18, 2024
@surchs surchs added flag:schedule Flag issue that should go on the roadmap or backlog. flag:discuss Flag issue that needs to be discussed before it can be implemented. and removed flag:schedule Flag issue that should go on the roadmap or backlog. labels Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flag:discuss Flag issue that needs to be discussed before it can be implemented.
Projects
Status: No status
Development

No branches or pull requests

2 participants