Dedicated bandwidth use case

[vvavepacket]

Hello, Say I have 5 machines.. I want these 5 machines to write to mergefs, and is it possible each machine writes to seperate hard disk at the same time?

Currently, by default, all writes are happening on a single drive. How do we configure it in a way where each machine will be writing to a dedicated drive so that they are transferring at full speed (120mb/sec)

Each machine has 1 gbit connection. and say merge FS will have 5 gigabit interfaces each have their own IP.

[trapexit]

Sorry, but you're being too vague about the situation. There is a lot more to that situation than perhaps meets the eye.

Describe using specific metrics available to mergerfs now or theoretically that would be used to make the decision which branch is selected when a create happens. f(X) = B. Where 'f' is the function / algo, 'X' the input to the function, 'B' being the branch to call create on. Exactly what the pattern of syscalls made are. Without this information it isn't possible to know how any particular policy would behave.

For example: a theoretical "least 'open for write' files" policy. How long are files open for write? Are the underlying branches on the same interconnects? Have the same theoretical performance characteristics? Are there other apps reading? Writing? At what pattern? Some torrent software do loops of "open, read/write, close" which would likely turn any such policy into nothing better than random but with more complexity.

[trapexit]

I don't mean to make this out to be overly complex... but the reality is that it is complex. It sounds easy to dedicate one branch to one create/open for write (and subsequent writes/reads) but that's only in the situation where N branches and at most N requests come in. But that situation is highly irregular. Most people all kinds of random stuff running interacting with their filesystem and even the slightest change to the access pattern could, depending on the algo and metrics used, completely change the situation.

We can't also forget that such a algo will be difficult to debug or follow as the data use would be extremely ephemeral. Understanding why something happened would require a full trace of said data that is currently not something that mergerfs does because any such thing would consume additional resources and rarely be used.