-
Notifications
You must be signed in to change notification settings - Fork 474
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
Capacity limit is ignored #345
Comments
This is one of the main reasons we switched to longhorn. Local path really isn't useful beyond testing. |
Hi @jcox10 ! Thanks for the info! Can Longhorn offer same as Local path provisioner in regard of local volumes. Meaning creating local volumes on the hard disk of every server? Ans second question if this holds true: Is there an easy switch from Local Path provisioner volumes to Longhorn ones? thanks |
Can you provide more information on your environment including the network env (1Gbps or 10 Gbps) and the underlying storage (SSD or HDD)? |
Hi @derekbit Rancher 2.6.8 We are curently using lpp to create volumes directly on our SSD disks, which works perfect. Only thing is missing is the limit. |
I see. In Longhorn, each volume has one or multiple replicas. The network is only 1Gbps which is a bit slow for Longhorn. However, in your use case, you use a volume with a local replica (set volume dataLocality to |
is there any future plan to support capacity limit? |
is there any future plan to support capacity limits - for example by using underlying FileSystem quotas? |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This issue was closed because it has been stalled for 5 days with no activity. |
Can this be re-opened? I think this would be a wonderful feature to add. It's listed in the README as a drawback |
Hi there!
On the README I read:
This means the Local path Provisioner does not respect the limits atm, right?
Are there any plans to implement this and if yes, when could we expect this? This would be a really needed feature. Otherwise one has no control - at least not within Kubernetes - for to avoid potential disk overflow.
best
Martin
The text was updated successfully, but these errors were encountered: