s3fs将Amazon S3存储桶作为本地目录装载的稳定性如何

s3fs在Linux上将Amazon S3存储桶挂载为本地目录的稳定性如何？在高需求的生产环境中是否推荐/稳定？

有更好的/类似的解决方案吗？

更新：使用EBS并通过NFS将其安装到所有其他AMI会更好吗？

在s3fs上有一篇不错的文章，阅读后我求助于EBS Share。

它强调了使用s3fs时应注意的一些重要注意事项，即与S3的固有局限性有关：

• 没有文件可以超过5GB
• 您无法部分更新文件，因此更改单个字节将重新上传整个文件。
• 对许多小文件的操作非常有效（毕竟每个文件都是一个单独的S3对象），但是大文件的效率很低
• 尽管S3支持部分/分块下载，但是s3fs并未利用此功能，因此，如果您只想读取1GB文件的一个字节，则必须下载整个GB。

因此，这取决于您存储的内容s3fs是否可行。如果您要存储照片，例如要在其中写入整个文件或读取整个文件的位置，而从不增量更改文件，那么它就可以了，尽管有人会问，如果您这样做，为什么不使用S3直接使用API​​？

如果您要谈论应用数据（例如数据库文件，日志文件），您希望在其中进行小的增量更改，那么它绝对不是-S3 Just不能那样工作，您无法增量更改文件。

上面提到的文章确实谈到了类似的应用程序s3backer，它通过在S3上实现虚拟文件系统来解决性能问题。这可以解决性能问题，但它本身也有一些问题：

• 由于延迟写入，数据损坏的风险很高
• 块尺寸太小（例如，默认为4K）会增加大量额外成本（例如，具有4K块存储容量的50GB的价格为130美元）
• 太大的块大小会增加大量的数据传输和存储费用。
• 内存使用可能会令人望而却步：默认情况下，它会缓存1000个块。
  使用默认的4K块大小不是问题，但是大多数用户
  可能会希望增加块大小。

我求助于EC2实例共享的EBS安装驱动器。但是您应该知道，尽管性能最高的选项有一个大问题，但EBS挂载NFS共享有其自身的问题-单点故障；如果共享EBS卷的计算机出现故障，则您将失去所有访问共享的计算机的访问权限。

这是我能够忍受的风险，也是我最终选择的选项。我希望这有帮助。

这是一个老问题，所以我将在过去的一年中与S3FS分享我的经验。

最初，它存在许多错误和内存泄漏（我每2个小时就有一次cron-job重新启动它），但是在最新的1.73版本中，它非常稳定。

关于S3FS的最好的事情就是您不必担心一件事情，并且可以免费获得一些性能优势。

您的大多数S3请求将是PUT（〜5％）和GET（〜95％）。如果不需要任何后期处理（例如，生成缩略图）。如果您不需要任何后期处理，则不应该首先访问Web服务器并直接将其上传到S3（使用CORS）。

假设您正在访问服务器，则可能意味着您需要对图像进行一些后处理。使用S3 API，您将上传到服务器，然后上传到S3。如果用户想要裁剪，则需要从S3重新下载，然后重新上传到服务器，裁剪然后再上传到S3。在启用S3FS和本地缓存的情况下，该编排将由您处理，并保存从S3下载的文件。

在缓存上，如果您缓存到​​EC2上的临时驱动器，则会获得随之而来的性能优势，并且可以清除缓存而不必担心任何事情。除非磁盘空间不足，否则没有理由清除缓存。这使遍历操作（例如搜索和过滤）更加容易。

我确实希望它与S3（RSync样式）完全同步。这样一来，它就可以成为Dropbox或S3的Google Drive的企业版，而不必与它附带的配额和费用进行竞争。