stanimirivanovde
commented
5 years ago Here is the pull request that addresses this issue:
Closed stanimirivanovde closed 5 years ago
stanimirivanovde
commented
5 years ago Here is the pull request that addresses this issue:
SerCeMan
commented
5 years ago Hi, @stanimirivanovde! Thank you for the pull request. Would the "blocking" option resolve this problem?
stanimirivanovde
commented
5 years ago Yes it should solve it as long as we run the blocking code in a thread in a new thread pool. This is basically what you're doing in the non-blocking case. So that could be an additional workaround along with the common ForkJoinPool parallelism JVM argument.
SerCeMan
commented
5 years ago
I am implementing a multiple FUSE drives support and I found that I had issues mounting more than 7 drives. Turns out that the issue is in the global ForkJoinPool that jnr-fuse uses to execute asynchronously a mount(). So once the pool is full it doesn't accept more tasks to be submitted and the system blocks until one of the drives is unmounted.
There is a workaround to this. You can increase the global ForkJoinPool parallelism level on startup by using this JVM argument:
'-Djava.util.concurrent.ForkJoinPool.common.parallelism=24'
This way you can have up to 24 drives mounted. Having the ability to configure the parallelism size of the pool would be nice, or we can create a new forkjoinpool for each mount with size of 1. This way we guarantee that we'll always execute a new mount given that the system doesn't crash. I'll submit a PR with this soon.
As a general guidance we have 3 different limitations on the number of drives we could support: osxfuse: 24 mounts (https://github.com/osxfuse/osxfuse/issues/152) libfuse: 1000 by default (probably can support a lot more) WinFsp: Windows should be limitted by the number of dirve letters: 25 because C:\ is guaranteed to be taken?