The number of FUSE mounts is capped by the number of CPUs

[stanimirivanovde]

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 (macfuse/macfuse#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?

[stanimirivanovde]

Here is the pull request that addresses this issue:

#79

[SerCeMan]

Hi, @stanimirivanovde! Thank you for the pull request. Would the "blocking" option resolve this problem?

[stanimirivanovde]

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]

Fixed in #79