常见问题

文档没能解答我的疑问

请首先尝试使用站内搜索功能（右上角），尝试用不同的关键词进行检索，如果文档始终未能解决你的疑问，请通过右下角的 Intercom 会话联系 Juicedata 团队。

为什么文件系统数据量与对象存储占用空间存在差异？

写入 JuiceFS 文件系统的数据，会上传到对象存储服务，但由于架构设计，文件系统的用量大小和实际对象存储的数据量一定会存在差异。一般来说，差异会在 5% 以内，但如果文件系统开启了压缩，或者大量使用 juicefs snapshot、硬链接等功能，差异会更大。

• 最典型和常见的导致用量不一致的场景，就是用户为自己的文件系统开启了回收站功能，被删除的文件不会立刻清理，而是保留指定时间后，才进行清理删除（在后台任务中进行）。

• 如果使用 juicefs snapshot 来复制文件或目录，那么只有元数据会被拷贝，并引用同一份对象存储数据。可想而知，如果大量使用克隆功能，JuiceFS 文件系统用量将显著大于对象存储数据量。关于克隆功能，还需要注意：

  • 如果所使用的 Linux 内核支持 copy_file_range，那么调用 cp 时，实际发生的也是同样的元数据拷贝，也会产生类似的情况。
  • ​私有部署 对于使用多分区集群的场景，调用 juicefs snapshot 时目的地横跨不同分区，仅在这种特殊情况下，JuiceFS 会将对象存储数据也异步拷贝一份，会增加对象存储用量。

• 如果在文件系统中创建硬链接，那么文件系统的用量统计会增加，但由于链接引用相同的底层对象存储文件，所以对象存储侧的数据并不会增加。

• 随机写、覆盖写相比其他写模式会产生更多的文件碎片，因此对象存储的占用空间会大于等于实际大小。文件碎片产生以后，会在客户端的后台任务中进行合并，并重新上传至对象存储，被合并重新写入后，已经失效的碎片仍旧占用着对象存储的空间。会默认保留 1 天，并在过期后被清理，如果后台任务的速度不够，可能会存在比较长的时间，造成对象存储用量增大。

• 如果在使用 JuiceFS 的过程中，遭遇长时间的对象存储服务异常，导致 DELETE 请求大量失败，那么重试多次尝试后会放弃删除请求，可能造成对象泄漏。如果对象存储用量显著大于 JuiceFS 文件系统数据量，可以用 juicefs gc 来进行扫描和检查，将扫描结果提交给 Juicedata 工程师，并一起判断属于何种情况、是否需要清理。

• 如果文件在打开的状态下被删除了，尽管已经无法在文件系统中看到这个文件，但仍有进程在使用它。为了保证已打开这个文件的进程的正常访问，对象存储数据不会被删除，直到所有进程都关闭该文件。

• 如果文件系统开启了压缩，那么对象存储上存储的对象有可能比实际文件大小更小（取决于不同类型文件的压缩比）。

• 如果你使用 juicefs import 或者「按需导入」功能，这属于特殊使用方式，不存在碎片合并、覆盖写等问题。

  如果导入了对象存储的整个桶，那么文件系统大小会等同于对象存储桶大小。如果只导入一部分，那么文件系统存储将会是对象存储桶内数据的子集。简而言之，在这种模式下，JuiceFS 会根据实际导入文件系统的数据量进行计费。

• 根据所使用对象存储的存储类型不同，云服务商可能会针对某些存储类型设置最小计量单位。例如阿里云 OSS 低频访问存储的最小计量单位是 64KB，如果单个文件小于 64KB 也会按照 64KB 计算。

• ​私有部署 对于自建对象存储，例如 MinIO，实际占用大小也受到存储类设置的影响。

JuiceFS 支持哪些公有云和服务区？

已经支持 AWS、Google Cloud、微软 Azure、阿里云、腾讯云、华为云、UCloud、青云、七牛云、百度云、金山云、网易云、京东云、DigitalOcean 的所有服务区。

JuiceFS 可以支持任何有 Linux 虚拟机和对象存储的云，如果您要使用公有云或服务区还没支持，请联系我们开通。

JuiceFS 也支持在企业自己公有云 VPC 和机房中独立部署，请与我们联系。