共计 7797 个字符，预计需要花费 20 分钟才能阅读完成。
JuiceFS 是一个创新性的软件产品，很多首次尝试的小伙伴对产品和用法感到很多纳闷，所以为了帮忙大家疾速了解并上手 JuiceFS，咱们整顿了 24 个对于 JuiceFS 经典的问题答案，置信通过这 24 问，大家对 JuiceFS 会有更清晰的意识，应用上也会更加得心应手。
1. JuiceFS 的根本能力是什么
JuiceFS 是一款面向云原生设计的高性能共享文件系统，在 Apache 2.0 开源协定下公布。提供齐备的 POSIX 兼容性，可将简直所有对象存储接入本地作为海量本地磁盘应用，亦可同时在跨平台、跨地区的不同主机上挂载读写。
2. JuiceFS 的性能如何
JuiceFS 是一个分布式文件系统，元数据拜访的延时取决于挂载点到服务端之间 1 到 2 个网络来回（通常 1-3 ms），数据拜访的延时取决于对象存储的延时 (通常 20-100 ms)。程序读写的吞吐量能够到 50MiB/s 至 2800MiB/s（查看 fio 测试后果），取决于网络带宽以及数据是否容易被压缩。
JuiceFS 内置多级缓存（被动生效），一旦缓存预热好，拜访的延时和吞吐量十分靠近单机文件系统的性能（FUSE 会带来大量的开销）。
3. JuiceFS 的运行的必要条件
在运行前，须要筹备元数据引擎与对象存储，元数据引擎中存储的是文件的名称，大小，批改工夫等元数据，而对象存储中存储的是文件的内容。
元数据引擎以后反对：Redis，TiKV，MySQL，PostgreSQL 等，以后元数据引擎的反对清单与具体配置参考如何设置元数据引擎文档
对象存储反对的就更多了，根本常见的对象存储都反对了，比方 AWS S3，阿里云 OSS，华为云 OBS，腾讯云 COS 等等，另外为了不便测试，还特地反对本地磁盘作为对象存储。以后对象存储的反对清单与具体配置参考如何设置对象存储文档
4. JuiceFS 应用的步骤
应用步骤非常简单，分两步，第一步格式化，第二步挂载到本地。上面就是应用 JuiceFS 与 Redis 将阿里云 OSS 挂载到本地的示例：
# 1. 格式化一个文件系统
juicefs format \
--storage oss \
--bucket https://zhijian-dev.oss-cn-hangzhou.aliyuncs.com \
--access-key xxxx \
--secret-key xxxx \
redis://localhost:6379/1 \
test1
# 2. 后盾挂载文件系统到 /tmp/jfs 目录
juicefs mount -d redis://localhost:6379/1 /tmp/jfs5. 最快体验 JuiceFS 的形式
我本地没有 Redis，也没有对象存储，是否体验 JuiceFS 那？当然能够，拉起 JuiceFS 服务须要元数据引擎以及对象存储两个组件，但在这两个组件咱们能够应用最简略的，比方元数据引擎用 SQLite 这个嵌入式数据库，而对象存储应用本地磁盘（format 时的 —bucket 参数不填即为默认参数，默认为应用本地磁盘作为对象存储，root 用户默认存储门路为 /var/jfs
，普通用户默认存储门路为 ~/.juicefs/local）。这样就能够只须要 JuiceFS 二进制不须要任何内部组件就能体验 JuiceFS 产品了。
# 1. 应用 sqlite 作为元数据引擎格式化文件系统
juicefs format "sqlite3://my-jfs.db" test1
# 2. 后盾挂载文件系统到 /tmp/jfs 目录
juicefs mount -d sqlite3://my-jfs.db /tmp/jfs6. 能够用 root 以外的用户挂载吗
[](https://juicefs.com/docs/zh/c…)
能够，JuiceFS 能够由任何用户挂载。默认的缓存目录是 $HOME/.juicefs/cache（macOS）或者 /var/jfsCache（Linux），请确保该用户对这个目录有写权限，或者切换到其它有权限的目录。请查看「客户端读缓存」理解更多信息。
7. JuiceFS 对 POSIX 协定的兼容性如何
JuiceFS 借助 Pjdfstest 和 LTP 来验证其对 POSIX 的兼容性，最终测试后果为通过了 pjdfstest 中的所有测试用例以及 LTP 中的绝大部分用例。
8. JuiceFS 除了一般挂载外还反对哪些形式拜访数据
除了一般挂载外，还反对以下几种形式：
- Kuberenetes CSI 驱动：通过 Kubernetes CSI 驱动的形式将 JuiceFS 作为 Kubernetes 集群的存储层，详情请参考「Kubernetes 应用 JuiceFS」。
- Hadoop Java SDK：不便在 Hadoop 体系中应用兼容 HDFS 接口的 Java 客户端拜访 JuiceFS。详情请参考「Hadoop 应用 JuiceFS」。
- S3 网关：通过 S3 协定拜访 JuiceFS，详情请参考「配置 JuiceFS S3 网关」。
- Docker Volume 插件：在 Docker 中方便使用 JuiceFS 的形式，详情请参考「Docker 应用 JuiceFS」。
- WebDAV 网关：通过 WebDAV 协定拜访 JuiceFS
9. 反对哨兵或者集群模式的 Redis 作为 JuiceFS 的元数据引擎吗？
反对，另外这里还有一篇 Redis 作为 JuiceFS 元数据引擎的最佳实际文章可供参考。
10. 如何测试 JuiceFS 的性能
将 JuiceFS Mount 到本地目录后，对这个目录执行 JuiceFS bench 命令。JuiceFS bench 命令会在该目录上进行大文件与小文件读写测试。比方：
# /tmp/jfs 是 JuiceFS 挂载在本地的目录
$ juicefs bench /tmp/jfs
Cleaning kernel cache, may ask for root privilege...
Password:
Write big blocks count: 1024 / 1024 [==============================================================] done
Read big blocks count: 1024 / 1024 [==============================================================] done
Write small blocks count: 100 / 100 [==============================================================] done
Read small blocks count: 100 / 100 [==============================================================] done
Stat small files count: 100 / 100 [==============================================================] done
Benchmark finished!
BlockSize: 1 MiB, BigFileSize: 1024 MiB, SmallFileSize: 128 KiB, SmallFileCount: 100, NumThreads: 1
+------------------+-----------------+--------------+
| ITEM | VALUE | COST |
+------------------+-----------------+--------------+
| Write big file | 1236.96 MiB/s | 0.83 s/file |
| Read big file | 2962.88 MiB/s | 0.35 s/file |
| Write small file | 2277.4 files/s | 0.44 ms/file |
| Read small file | 2753.0 files/s | 0.36 ms/file |
| Stat file | 16603.3 files/s | 0.06 ms/file |
+------------------+-----------------+--------------+juicefs bench命令还能够作为 mount 后的简略的测试不便疾速判断 JuiceFS 服务是否失常。更多对于 JuiceFS 性能测试相干的问题能够看这篇性能评估指南文档
11. 如何测试对象存储的兼容性与性能
对象存储是 JuiceFS 的重要的组件，对象存储的正确性与性能间接影响 JuiceFS 服务的正确性与性能，所以当 JuiceFS 呈现问题的时候能够尝试先排除对象存储出问题的可能性。为了不便大家测试，咱们内置了 juicefs objbench 命令，该命令能够疾速测试对象存储的正确性以及其性能。示例：
$ juicefs objbench --storage minio http://127.0.0.1:9000/testbucket --access-key admin --secret-key admin123
Start Functional Testing ...
+----------+---------------------+-------------+
| CATEGORY | TEST | RESULT |
+----------+---------------------+-------------+
| basic | create a bucket | pass |
| basic | put an object | pass |
| basic | get an object | pass |
| basic | get non-exist | pass |
| basic | get partial object | pass |
| basic | head an object | pass |
| basic | delete an object | pass |
| basic | delete non-exist | pass |
| basic | list objects | pass |
| sync | put a big object | pass |
| sync | put an empty object | pass |
| sync | multipart upload | pass |
| sync | change owner/group | not support |
| sync | change permission | not support |
| sync | change mtime | not support |
+----------+---------------------+-------------+
Start Performance Testing ...
put small objects count: 100 / 100 [==============================================================] done
get small objects count: 100 / 100 [==============================================================] done
upload objects count: 256 / 256 [==============================================================] done
download objects count: 256 / 256 [==============================================================] done
list objects count: 100 / 100 [==============================================================] done
head objects count: 100 / 100 [==============================================================] done
delete objects count: 100 / 100 [==============================================================] done
Benchmark finished! block-size: 4096 KiB, big-object-size: 1024 MiB, small-object-size: 128 KiB, small-objects: 100, NumThreads: 4
+--------------------+--------------------+-----------------+
| ITEM | VALUE | COST |
+--------------------+--------------------+-----------------+
| upload objects | 67.12 MiB/s | 59.59 ms/object |
| download objects | 106.86 MiB/s | 37.43 ms/object |
| put small objects | 508.2 objects/s | 1.97 ms/object |
| get small objects | 728.0 objects/s | 1.37 ms/object |
| list objects | 46890.01 objects/s | 2.13 ms/op |
| head objects | 2861.2 objects/s | 0.35 ms/object |
| delete objects | 2295.1 objects/s | 0.44 ms/object |
| change permissions | not support | not support |
| change owner/group | not support | not support |
| update mtime | not support | not support |
+--------------------+--------------------+-----------------+12. 卸载挂载点报 Resource busy -- try 'diskutil unmount' 谬误
这代表挂载点下的某个文件或者目录正在被应用，无奈间接 umount，能够查看（如通过 lsof 命令）是否有关上的终端正位于 JuiceFS 挂载点的某个目录，或者某个应用程序正在解决挂载点中的文件。如果有，则退出终端或应用程序后再尝试应用 juicefs umount 命令卸载文件系统。
13. 如何销毁一个文件系统
应用 juicefs destroy 命令销毁一个文件系统，该命令将会清空元数据引擎与对象存储中的相干数据。对于该命令的应用详情请参考文档。
14. JuiceFS 的日志在哪里
JuiceFS 后盾挂载的时候日志才会写入日志文件，前台挂载或者其余前台的命令都会将日志间接打印到终端
Mac 零碎上日志文件默认是/Users/$User/.juicefs/juicefs.log
Linux 零碎上日志文件默认是/var/log/juicefs.log
15. 为什么在对象存储中看不到存入 JuiceFS 的原文件
应用 JuiceFS，文件最终会被拆分成 Chunks、Slices 和 Blocks 存储在对象存储。因而，你会发现在对象存储平台的文件浏览器中找不到存入 JuiceFS 的源文件，存储桶中只有一个 chunks 目录和一堆数字编号的目录和文件。不要惊恐，这正是 JuiceFS 文件系统高性能运作的秘诀！详情参考 JuiceFS 如何存储文件。
16. JuiceFS 随机写的基本原理是什么
JuiceFS 不将原始文件存入对象存储，而是将其依照某个大小（默认为 4MiB）拆分为 N 个数据块（Block）后，上传到对象存储，而后将数据块的 ID 存入元数据引擎。随机写的时候，逻辑上是要笼罩本来的内容，实际上是把 要笼罩的数据块 的元数据标记为旧数据，同时只上传随机写时产生的 新数据块 到对象存储，并将 新数据块 对应的元数据更新到元数据引擎中。
当读取被笼罩局部的数据时，依据 最新的元数据 ，从随机写时上传的 新数据块 读取即可，同时 旧数据块 可能会被后盾运行的垃圾回收工作主动清理。这样就将随机写的复杂度转移到读的复杂度上，。
这个只是很粗略的实现逻辑介绍，具体的读写流程非常复杂，能够研读 JuiceFS 外部实现与读写流程这两篇文档并联合代码一起梳理。
17. 为什么我在挂载点删除了文件，然而对象存储占用空间没有变动或者变动很小
第一个起因是你可能开起了回收站个性，为了保障数据安全回收站默认开启，删除的文件其实被放到了回收站，理论并没有被删除，所以对象存储大小不会变动。回收站的保留工夫能够通过 juicefs format指定或者通过 juicefs config 批改。请参考「回收站」文档理解更多信息。
第二个起因是 JuiceFS 是异步删除对象存储中的数据，所以对象存储的空间变动会慢一点。如果你须要立刻清理对象存储中须要被删除的数据，能够尝试运行 juicefs gc 命令。
18. 为什么挂载点显示的大小与对象存储占用空间存在差别
通过「JuiceFS 反对随机写的实现原理是什么？」这个问题的答案能够推断出，对象存储的占用空间大部分状况下是大于等于理论大小的，尤其是短时间内进行大量的笼罩写产生许多文件碎片后。这些碎片在未触发合并与回收前其仍旧占用着对象存储的空间。不过也不用放心这些碎片始终占用空间，因为在每次读/写文件的时候都会查看并在必要的时候触发该文件相干碎片的整顿工作。另外你能够通过 juicefs gc —-compact -—delete 命令手动触发合并与回收。
另外如果 JuiceFS 文件系统开启了压缩性能（默认不开启），那么对象存储上存储的对象有可能比理论文件大小更小（取决于不同类型文件的压缩比）。
如果以上因素都曾经排除，请查看你应用的对象存储的存储类型是什么，云服务商可能会针对某些存储类型设置最小计量单位。例如阿里云 OSS 低频拜访存储的最小计量单位是 64KB，如果单个文件小于 64KB 也会依照 64KB 计算。
19. JuiceFS S3 网关反对多用户治理等高级性能吗
JuiceFS 内置的 gateway 子命令不反对多用户治理等性能，只提供根本的 S3 Gateway 性能。如果须要应用这些高级性能，能够参考咱们的这个仓库，其将 JuiceFS 作为 MinIO gateway 后端的一种实现，反对 MinIO gateway 的残缺性能。
20. JuiceFS 与 XXX 的区别是什么
请查看「同类技术比照」文档理解更多信息。
21. JuiceFS 反对应用对象存储中的某个目录作为 —-bucket 选项的值吗
到 JuiceFS 1.0.0-rc3 为止，还不反对该性能。
22. JuiceFS 反对读取对象存储中曾经存在的数据吗
到 JuiceFS 1.0.0-rc3 为止，还不反对该性能。
23. JuiceFS 目前反对分布式缓存吗
到 JuiceFS 1.0.0-rc3 为止，还不反对该性能
24. JuiceFS 目前有 SDK 能够应用吗
截止到 JuiceFS 1.0.0-rc3 公布，社区有两个 SDK，一个是 Juicedata 官网保护的 HDFS 接口高度兼容的 Java SDK，另一个是由社区用户保护的 Python SDK。
如有帮忙的话欢送关注咱们我的项目 Juicedata/JuiceFS 哟！(0ᴗ0✿)
