 |
This is a current limitation and there is no easy way to fix this. The Director only knows about Storages and has no idea on which Storage Daemon that Storage is located. |
|
|
can you set a max on the director and also on each storage daemon? The director could then query each storage daemon to see what has been set? :) |
|
|
The director doesn't know there is a storage daemon. It just knows there is a storage and it can be accessed using an address, name and pre-shared key. To apply any limitations on a per storage daemon basis the director first needs to know what a storage daemon is. Definitely doable, but neither simple nor on our roadmap. |
|
|
As soon as it connects to that storage, would it be possible to simply assign jobs (like now it the case). After that the storage daemon decides how many he wants to run concurrently. Still the director should be smart enough to more or less evenly distribute jobs to different storage daemons. Let's say we put 24 as a max jobs for director, then the limit on the storage daemon is 8. Then at least the daemons would be protected from overloading. How do other people with multi storage daemons cope with this? It's really not very scalable like this while the architecture seems to be designed for that? :) |
|
|
I don't think we're going to work on that, tbh. |
- Anonymous
