[bmurphy1976]

As always, it depends on your use case. Just because it can be slow doesn't mean it's not a viable (and in some cases superior) option.

We use it to store petabytes of large video files and our system is structured such that no folder ever has more than a couple files in it (>20 is rare). With properly tuned caching this works fantastically well for our use case and I would take the simpler code and reduced points of failure over NFS nonsense any day.

That of course doesn't mean s3fs is the solution to every problem, it simply means it's good to have options and don't write something off because it "might be slow."

Know your data, know your use case, and know your tools. You can make smart decisions on your own rather than driven by anecdotal comments on HN.

[fi788]

I agree with your points. It is indeed a viable, if somewhat clunky solution.

For getting the data into S3, we found exponential improvements in using the AWS CLI, as I believe it handles uploads in a multi-threaded way.

S3fs turned out to be viable for our use case, storing Magento Enterprise content assets which are then served directly from S3, so the app's upload features rely on s3fs as well as the file checks from the app itself (which are indeed quite slow).

I've always wanted to do it natively, mounting EBS volumes on more than one instance (which is not currently possible) or wishing for a native NFS service like AWS released.

All in all, it is a happy day for me. More options make us more powerful.

[moe]

Which s3fs are you using?

The fuse-based ones that I've tried were ridden with problems and poor error handling. Hangs and truncated files were the rule rather than the exception.

[gaul]

s3fs-fuse has its share of problems, but master has fixes for some of the error handling and truncated files issues. Please report any bugs you encounter on GitHub!