[daviesliu]

Usually the meta engine or object storage can scale horizontally by itself, JuiceFS is middleware to talk to these two services.

To serve S3 request, you can setup multiple S3 gateway and put a load director in front of them.

[hardwaresofton]

> Usually the meta engine or object storage can scale horizontally by itself, JuiceFS is middleware to talk to these two services.

Thanks for confirming this -- I spent a bunch of time reading and was wondering why I couldn't find anything... this answers my question.

I think I misunderstood JuiceFS -- it's more like a better rclone than it is a distributed file system. It's a swiss army knife for mounting remote filesystems.

Assuming you're using a large object service (S3, GCP, Backblaze, etc) then the scale issue is expected to be solved. If you're using filesystem or local minio for example, then you have to solve the problem yourself.

> To serve S3 request, you can setup multiple S3 gateway and put a load director in front of them.

This is exactly the question I had -- it occurred to me that if I make 2 s3 gateways, even if they share the metadata store they might be looking at resources that only one can serve.

So in this situation:

    [metadata (redis)]-->[ram]
      |
    [s3-0]-->[local disk]
      |
    [s3-1]-->[local disk]

In that situation, then if a request came in to s3-0 for data that was stored @ s3-1, the request would fail, correct? Because s3-0 has no way of redirecting the read request to s3-1.

This could work if you had an intelligent router sitting either in front the s3s (so you could send reads/writes to a certain one of them that is known to have the data), but by default, your writes would fail, I'm assuming.

Oh I have one more question -- can you give options to the sshfs module? It seems like you can just append `?SSHOptionHere=x` to `--bucket` but I'm not sure (ex. `--bucket user@box?SshOption=1`)