-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
[Bug]- weed couldn't estimate the free space of destination disks for transferring ec shards even after adjusting "Max" option to 0 #2642
Comments
The volumes are balanced according to the volume "slots", not based on the actual free space. For your case, you can move some of the 218 volumes to other servers, to get to an expected normal state. |
@chrislusf |
maybe share "volume.list" result (again) and I will try to reproduce it locally. |
Here you are @chrislusf : |
the volume.list output is malformed. |
New output @chrislusf : |
Is the new file format I've uploaded correct @chrislusf ?
|
Works now. Added a fix. |
Hi @chrislusf ,
This is the second time that I tried to encode another volume
Many thanks. |
Hi, @chrislusf
Based on our conversation about this issue, I reconfigure my cluster config and I adjust the "Max " option to "0"
and weed examined the best number for it based on the disk size,
for example, my disk has 7.3 TB of space and weed adjusted max parameter to 73
It's good but in some disks, with the same amount of space it sets the max number to 218 or even more for example
weed-volume-005.local:8082 has 7.3TB but weed adjust 218 caused an error for transferring shards.
This is because of the count of volumes that were in that specific disks
This will cause problems in encoding volumes to ec shards and even concurrency about some volumes of a collection (because volumes of that collection are not filled to weed create a new one and disk is full and weed couldn't accept more objects and files to save on volumes)
I test ec.encode again and I got the error about it:
weed-volume-005.local:8082 is the one that has 218 volume and cause the following error:
Why weed is trying to transfer shards to a volume with max number of 218 and is filled with 218 volumes?
Isn't better for weed to estimate the free space of destination based on the actual free space, not just the count of volumes?
The text was updated successfully, but these errors were encountered: