Skip to main content

问题排查案例

这里收录常见问题的具体排查步骤。在排查之前，首先用 juicefs version 确认自己所使用的客户端版本，如果过于老旧（比如发布时间超过半年），推荐先升级到最新版本客户端，提前隔离旧版问题：

# 用 --restart 来顺便平滑重启挂载点
juicefs version --upgrade --restart

挂载失败 / 挂载时卡住​

在挂载命令后面加上 --foreground --verbose 参数，让挂载进程运行在前台，方便阅读错误输出：

juicefs mount $VOL_NAME /jfs --foreground --verbose

常见的错误比如：

  • AK/SK 填写错误，导致调用对象存储 API 创建存储桶失败。

  • 解析域名失败，无法连接元数据服务，那么需要确认上游 DNS 服务器正常运作，并刷新本地 DNS 缓存。

  • 能够成功解析域名，但是无法与元数据服务器建立连接，很可能是由于防火墙限制了端口访问。需要确保挂载的机器能够访问外网 9300 - 9500 TCP 端口使其能与我们的元数据服务器通信，以 iptables 为例：

    iptables -A OUTPUT -p tcp --match multiport --dports 9300:9500 -j ACCEPT

    如果你使用的是公有云平台的安全组，登录公有云的控制台进行相应调整。

  • 私有部署 挂载命令成功执行，宿主机挂载点也能正常运行，但短暂过后，挂载点莫名消失。这种情况往往是由于宿主机存在遗留的挂载守护进程导致的。

    JuiceFS 客户端运行时，会产生挂载进程（Go 二进制）和守护进程（Python）。如果集群发生了元数据节点迁移，迁移期间的特殊操作（比如强行卸载）会导致挂载进程丢失，但守护进程仍然正常运作。此时再次执行挂载，虽然挂载点能正常创建，但遗留的守护进程由于元数据服务配置变动，会不断尝试卸载挂载点，并反复尝试重连，并因配置过期而无法成功。这时用以下命令清理守护进程并重试：

    # 定位遗留的 JuiceFS 客户端守护进程，守护进程由 Python 运行
    ps -ef | grep juicefs

    # 记录守护进程的 PID，用 kill 终结进程，然后重试挂载
    kill $PID

读写失败​

JuiceFS 的读写失败可能由多种多样的原因构成，无法一一列举。不过在发生读写错误时，你总能在客户端日志（默认 /var/log/juicefs.log，详见 mount 参数）里找到报错原因，在这里介绍一些常见故障和排查步骤。

无法与元数据服务通信​

JuiceFS 客户端需要时刻与元数据集群保持畅通网络连接，才能高速访问元数据服务。如果运行途中网络访问中断，一般会看见大量类似下方日志：

<ERROR>: request 402 (40) timeout after 1.000603709s
<ERROR>: request 428 (3283870) failed after tried 30 times

以上日志中的 request 402 和 request 428 都是客户端与元数据服务通信的 RPC 命令代号，大部分属于文件系统的元数据操作。如果日志中大量出现此类 RPC 请求超时的错误，可以用下方命令进行排查：

# 在 TCP 连接里定位到客户端连接的元数据服务地址
lsof -iTCP -sTCP:ESTABLISHED | grep jfsmount
# 如果客户端已经卸载，找不到 TCP 连接，也可以直接在配置文件里找到元数据服务地址
grep master ~/.juicefs/$VOL_NAME.conf

# 确保对元数据服务端口访问畅通（假设元数据服务地址为 aliyun-bj-1.meta.juicefs.com）
telnet aliyun-bj-1.meta.juicefs.com 9402
# 如果没安装 telnet，也可用 curl / wget，但由于元数据服务并不是 HTTP 协议，只能给出空响应
curl aliyun-bj-1.meta.juicefs.com:9402
# curl: (52) Empty reply from server

# 如果域名无法解析，则需要检查 master_ip 是否能正常访问，master_ip 同样在配置文件中可获得
grep master_ip -A 3 ~/.juicefs/$VOL_NAME.conf
# 用上方的网络排查命令确认 IP 能正常访问

# 如果域名能正常解析，确认结果与配置文件中 master_ip 匹配
dig aliyun-bj-1.meta.juicefs.com

经历上方排查，可能出现的问题以及处理手段如下：

域名无法解析

在云服务中，元数据服务域名在公网就能顺利解析，如果客户端无法解析该域名，多半表明宿主机的 DNS 配置有问题，需要予以排查。

不过事实上，就算域名无法解析，只要客户端能顺利访问元数据服务节点的 IP（配置文件中的 master_ip），JuiceFS 客户端就能正常工作。因此在私有部署中，并不强求域名一定可以解析，域名的存在主要是为了灾备，如果元数据服务节点不会发生且不打算迁移，可以不设置域名解析（会产生一些 WARNING 日志）。但如果设置了，一定要设置正确，不要为了避免 WARNING 日志而「乱加域名解析」，否则客户端万一需要重连元数据服务节点，通过错误的域名解析结果拿到了无法连接的地址，也会直接报错导致挂载无法使用。

master_ip 无法正常访问

在云服务中，客户端一般通过公网 IP 连接元数据服务，如果 IP 无法正常访问，作如下排查：

  • 如果 curl、ping 等探测命令发生 timeout，往往是安全组、防火墙设置有误，导致丢包，应予以排查。
  • 私有部署 如果对元数据服务端口（默认 9402）探测结果为 `Connection Refused`，则可以认为访问畅通，但元数据服务没有在正常运行。
  • 私有部署 如果已经为元数据服务设置了域名解析，可以按照上方排查示范命令，检查域名解析的结果与配置文件中的 `master_ip` 匹配，如果二者不相同，根据实际情况修复域名解析，或者重新挂载。

元数据请求超时​

通常而言，元数据请求只占用很少带宽。如果确认网络畅通，却频频发生类似 <ERROR>: request 402 (40) timeout after 1s 的超时日志，没有明确的文件系统访问报错，只伴随着读写性能不稳定，那么从以下角度进行排查：

  • 在监控确认与元数据节点的 ping 延迟，如果存在延迟波动，并且时间点与 timeout 日志吻合，那么很可能是网络抖动所致；
  • 在监控确认客户端节点的 CPU 用量，与宿主机实际 CPU 用量进行比对。对于容器，则需要确认资源声明，以及宿主机实际资源用量，确定没有因为超售资源而发生挤兑。如果客户端资源不足，发生了 CPU Throttle，也有可能出现请求 timeout，同时伴随着性能下降；
  • 私有部署 在 Grafana 中打开 JuiceFS Meta info 监控面板，重点关注 CPU 面板。正常情况下，`syscpu` 用量应该偏低（3%-20%），如果 `syscpu` 接近 100%，意味着元数据服务已经面临性能问题，容易导致客户端请求超时；
  • 私有部署 如果通过类似跨区域网络专线（例如 AWS Direct Connect、Azure ExpressRoute）的方式访问元数据服务，发生带宽挤占时，元数据请求性能可能急剧下降，并在元数据服务日志中产生类似 `outgoing queue of x.x.x.x:xxx (955107) is full, create a buffer (10240) for it` 的日志，这表示需要发送给客户端的流量大于实际网络带宽，因此只好暂存在缓冲区，然后重试。

与对象存储通信不畅（网速慢）​

如果无法访问对象存储，或者仅仅是网速太慢，JuiceFS 客户端也会发生读写错误。你也可以在日志中找到相应的报错。

# 上传块的速度不符合预期
<INFO>: slow request: PUT chunks/1986/1986377/1986377131_11_4194304 (%!s(<nil>), 20.512s)

# 上传失败还可能伴随着打印堆栈信息，阅读出错的函数名，可推测是对象存储上传失败
<ERROR>: flush 9902558 timeout after waited 8m0s [writedata.go:604]
<ERROR>: pending slice 9902558-80: {chd:0xc0007125c0 off:0 chunkid:1986377183 cleng:12128803 soff:0 slen:12128803 writer:0xc010a92240 freezed:true done:false status:0 notify:0xc010e57d70 started:{wall:13891666526241100901 ext:5140404761832 loc:0x35177c0} lastMod:{wall:13891666526250536970 ext:5140414197911 loc:0x35177c0}} [writedata.go:607]
<WARNING>: All goroutines (718):
goroutine 14275 [running]:
jfs/mount/fs.(*inodewdata).flush(0xc004ec6fc0, {0x7fbc06385918, 0xc00a08c140}, 0x0?)
    /p8s/root/jfs/mount/fs/writedata.go:611 +0x545
jfs/mount/fs.(*inodewdata).Flush(0xc0007ba1e0?, {0x7fbc06385918?, 0xc00a08c140?})
    /p8s/root/jfs/mount/fs/writedata.go:632 +0x25
jfs/mount/vfs.Flush({0x2487e98?, 0xc00a08c140}, 0x9719de, 0x8, 0x488c0e?)
    /p8s/root/jfs/mount/vfs/vfs.go:1099 +0x2c3
jfs/mount/fuse.(*JFS).Flush(0x1901a65?, 0xc0020cc1b0?, 0xc00834e3d8)
    /p8s/root/jfs/mount/fuse/fuse.go:348 +0x8e
...
goroutine 26277 [chan send, 9 minutes]:
jfs/mount/chunk.(*wChunk).asyncUpload(0xc005f5a600, {0x0?, 0x0?}, {0xc00f849f50, 0x28}, 0xc0101e55e0, {0xc010caac80, 0x4d})
    /p8s/root/jfs/mount/chunk/cached_store.go:531 +0x2e5
created by jfs/mount/chunk.(*wChunk).upload.func1
    /p8s/root/jfs/mount/chunk/cached_store.go:615 +0x30c
...

如果是网络异常导致无法访问，或者对象存储本身服务异常，问题排查相对简单。但在如果是在低带宽场景下希望优化 JuiceFS 的使用体验，需要留意的事情就稍微多一些。

首先，在网速慢的时候，JuiceFS 客户端上传／下载文件容易超时（类似上方的错误日志），这种情况下可以考虑：

  • 降低上传并发度，比如 --max-uploads=1，避免上传超时。
  • 降低上传速率，比如用 --upload-limit=10 限制上传速度为 10Mbps。
  • 降低读写缓冲区大小，比如 --buffer-size=64 或者更小。当带宽充裕时，增大读写缓冲区能提升并发性能。但在低带宽场景下使用过大的读写缓冲区，flush 的上传时间会很长，因此容易超时。
  • 默认 GET / PUT 请求超时时间为 60 秒，因此增大 --get-timeout 以及 --put-timeout，可以改善读写超时的情况。

做完相关调整以后，可以用 nethogs 查看每个进程使用网络的情况：

此外，低带宽环境下需要慎用「客户端写缓存」特性。先简单介绍一下 JuiceFS 的后台任务设计：每个 JuiceFS 客户端默认都启用后台任务，后台任务中会执行碎片合并（Compaction）、异步删除等工作，而如果节点网络状况太差，则会降低系统整体性能。更糟的是如果该节点还启用了客户端写缓存，则容易出现碎片合并后上传缓慢，导致其他节点无法读取该文件的危险情况：

# 由于 writeback，碎片合并后的结果迟迟上传不成功，导致其他节点读取文件报错
<WARNING>: readworker: unexpected data block size (requested: 4194304 / received: 0)
<ERROR>: read for inode 0:14029704 failed after tried 30 times
<ERROR>: read file 14029704: input/output error
<INFO>: slow operation: read (14029704,131072,0): input/output error (0) <74.147891>
<WARNING>: fail to read chunkid 1771585458 (off:4194304, size:4194304, clen: 37746372): get chunks/1771/1771585/1771585458_1_4194304: oss: service returned error: StatusCode=404, ErrorCode=NoSuchKey, ErrorMessage="The specified key does not exist.", RequestId=62E8FB058C0B5C3134CB80B6
<WARNING>: readworker: unexpected data block size (requested: 4194304 / received: 0)
<WARNING>: fail to read chunkid 1771585458 (off:0, size:4194304, clen: 37746372): get chunks/1771/1771585/1771585458_0_4194304: oss: service returned error: StatusCode=404, ErrorCode=NoSuchKey, ErrorMessage="The specified key does not exist.", RequestId=62E8FB05AC30323537AD735D

为了避免此类问题，我们推荐在低带宽节点上禁用后台任务。你需要在控制台“访问控制”页面，创建新的“客户端访问令牌”，并取消勾选“允许后台任务”，最后用新生成的 Token 来执行客户端挂载。

警告日志：找不到对象存储块​

规模化使用 JuiceFS 时，往往会在客户端日志中看到类似以下警告：

<WARNING>: fail to read sliceId 1771585458 (off:4194304, size:4194304, clen: 37746372): get chunks/0/0/1_0_4194304: oss: service returned error: StatusCode=404, ErrorCode=NoSuchKey, ErrorMessage="The specified key does not exist.", RequestId=62E8FB058C0B5C3134CB80B6

出现这一类警告时，如果并未伴随着访问异常（比如日志中出现 input/output error），其实不必特意关注，客户端会自行重试，往往不影响文件访问。

这行警告日志的含义是：访问 Slice 出错了，因为对应的某个 Block 不存在，对象存储返回了 NoSuchKey 错误。出现此类异常的可能原因有下：

  • JuiceFS 客户端默认会在后台任务运行碎片合并（Compaction），碎片合并完成后，文件与对象存储数据块（Block）的关系随之改变，但此时可能其他客户端正在读取该文件，因此随即报错。
  • 某些客户端开启了「写缓存」，文件已经写入，提交到了元数据服务，但对应的对象存储 Block 却并未上传完成（比如网速慢），导致其他客户端在读取该文件时，对象存储返回数据不存在。

再次强调，如果并未出现应用端访问异常，则可安全忽略此类警告。

读放大​

在 JuiceFS 中，一个典型的读放大现象是：对象存储的下行流量，远大于实际读文件的速度。比方说 JuiceFS 客户端的读吞吐为 200MiB/s，但是在 S3 观察到了 2GB/s 的下行流量。

JuiceFS 中内置了预读（prefetch）机制：随机读 block 的某一段，会触发整个 block 下载，这个默认开启的读优化策略，在某些场景下会带来读放大。了解这个设计以后，我们就可以开始排查了。

结合先前问题排查方法一章中介绍的访问日志知识，我们可以采集一些访问日志来分析程序的读模式，然后针对性地调整配置。下面是一个实际生产环境案例的排查过程：

# 收集一段时间的访问日志，比如 30 秒：
cat /jfs/.oplog | grep -v "^#$" >> op.log

# 用 wc、grep 等工具简单统计发现，访问日志中大多都是 read 请求：
wc -l op.log
grep "read (" op.log | wc -l

# 选取一个文件，通过 inode 追踪其访问模式，read 的输入参数里，第一个就是 inode：
grep "read (148153116," op.log

采集到该文件的访问日志如下：

2022.09.22 08:55:21.013121 [uid:0,gid:0,pid:0] read (148153116,131072,28668010496,19235): OK (131072) <1.309992>
2022.09.22 08:55:21.577944 [uid:0,gid:0,pid:0] read (148153116,131072,14342746112,19235): OK (131072) <1.385073>
2022.09.22 08:55:22.098133 [uid:0,gid:0,pid:0] read (148153116,131072,35781816320,19235): OK (131072) <1.301371>
2022.09.22 08:55:22.883285 [uid:0,gid:0,pid:0] read (148153116,131072,3570397184,19235): OK (131072) <1.305064>
2022.09.22 08:55:23.362654 [uid:0,gid:0,pid:0] read (148153116,131072,100420673536,19235): OK (131072) <1.264290>
2022.09.22 08:55:24.068733 [uid:0,gid:0,pid:0] read (148153116,131072,48602152960,19235): OK (131072) <1.185206>
2022.09.22 08:55:25.351035 [uid:0,gid:0,pid:0] read (148153116,131072,60529270784,19235): OK (131072) <1.282066>
2022.09.22 08:55:26.631518 [uid:0,gid:0,pid:0] read (148153116,131072,4255297536,19235): OK (131072) <1.280236>
2022.09.22 08:55:27.724882 [uid:0,gid:0,pid:0] read (148153116,131072,715698176,19235): OK (131072) <1.093108>
2022.09.22 08:55:31.049944 [uid:0,gid:0,pid:0] read (148153116,131072,8233349120,19233): OK (131072) <1.020763>
2022.09.22 08:55:32.055613 [uid:0,gid:0,pid:0] read (148153116,131072,119523176448,19233): OK (131072) <1.005430>
2022.09.22 08:55:32.056935 [uid:0,gid:0,pid:0] read (148153116,131072,44287774720,19233): OK (131072) <0.001099>
2022.09.22 08:55:33.045164 [uid:0,gid:0,pid:0] read (148153116,131072,1323794432,19233): OK (131072) <0.988074>
2022.09.22 08:55:36.502687 [uid:0,gid:0,pid:0] read (148153116,131072,47760637952,19235): OK (131072) <1.184290>
2022.09.22 08:55:38.525879 [uid:0,gid:0,pid:0] read (148153116,131072,53434183680,19203): OK (131072) <0.096732>

对着日志观察下来，发现读文件的行为大体上是「频繁随机小读」。我们尤其注意到 offset（也就是 read 的第三个参数）跳跃巨大，说明相邻的读操作之间跨度很大，难以利用到预读提前下载下来的数据（默认的块大小是 4MiB，换算为 4194304 字节的 offset）。也正因此，我们建议将 --prefetch 调整为 0（让预读并发度为 0，也就是禁用该行为），并重新挂载。这样一来，在该场景下的读放大问题得到很好的改善。

分布式缓存、独立缓存集群相关问题​

如果在使用分布式缓存时发现缓存命中率低，或者不断波动，那么在开始排查前，我们推荐：

  • 为所有缓存组成员节点启用 DEBUG 日志，同时注意日志中的 peer 字样——缓存组成员变动时，日志里往往含有这个单词。
  • 查看缓存集群相关监控项，也可以直接在 Grafana 中查看标题含有「Remote cache」字样的相关监控面板。

在独立缓存集群场景下，我们通常会提前预热好数据，如果预热完成后，仍然观察到缓存利用率不如预期，参考以下排查要点：

预热是否真的成功？

juicefs warmup 会忽略预热过程中的下载超时等异常，就算命令成功执行，也未必意味着数据完整地下载到了本地。你可以手动确认下缓存目录大小（比如 du --max-depth 1 -h /var/jfsCache），或者重新执行 juicefs warmup 命令来重试。

如果重复预热也无法完整下载全部数据，遵循以下排查路径：

  • juicefs warmup 命令作用于当前挂载点上，因此对于该挂载点，增加 --verbose 参数，开启打印 DEBUG 日志，阅读报错日志。比方说：

    <ERROR>: xxx could be corrupted: chunk x:x:xxx is not available: read header: EOF

    这代表着缓存组成员在下载对象存储块时发生了失败，失败的原因是多种多样的，需要继续查看缓存组成员的客户端日志，才能进一步排查。

  • 对于缓存组成员（缓存集群），也启用 --verbose，然后查看成员节点的客户端日志。warmup 途中如果发生下载失败，会在日志中体现原因，结合下方的排查案例进行分析。

缓存组成员节点，是否有多块网卡？绑定网卡是否正确？

如果缓存集群成员节点有多块网卡，所属的网络不互通，或者带宽受限，不适合缓存集群使用，这时需要确定合适的网卡，你可以用类似下方的命令，来确认网络互通：

# 进入缓存集群成员节点或容器
# 对于缓存组成员，JuiceFS 客户端会随机监听本地端口，用于组内成员通信
# 默认 pprof 会监听 6060 与 6070，分布式缓存服务的监听端口通常是最大的那一个
lsof -PiTCP -sTCP:LISTEN | grep jfs

# 进入客户端节点或容器，尝试连接缓存集群端口，确认网络连通性
telnet [member-ip] [port]

如果排查发现确实需要更换缓存集群的监听网卡，那么需要在挂载命令用 --group-ip 指定对应的网卡 IP。注意，--group-ip 还可以指定 CIDR 前缀，比方说需要监听的网卡 IP 段为 172.16.0.0/16，那么可以直接指定 --group-ip=172.16.0.0，这样一来，缓存集群节点就可以使用统一的挂载参数，方便管理。

缓存组成员内网带宽是否受限？

组建 JuiceFS 分布式缓存的节点建议至少以万兆网互联，如果在低带宽的网络下构建缓存组，比方说千兆网络，则可能发生如下报错：

# 内网带宽太差，或者网络不互通
<INFO>: remove peer 10.8.88.242:40010 after 31 failure in a row [peer.go:532]

# 如果内网互通，但只是网络质量太差，成员被移除出缓存组后，还可能迅速被加回缓存组
<INFO>: add peer 10.8.88.242:40010 back after 829.247µs [peer.go:538]

# 从组内成员获取数据块失败
<WARNING>: failed to get chunks/6C/4/4020588_14_4194304 for 10.6.6.241:38282: timeout after 1m0s [peer.go:667]
<ERROR>: /fio_test/read4M-seq.2.0 could be corrupted: chunk 1:0:4020660 is not available: read header: read tcp 10.8.88.241:34526->10.8.88.242:40010: i/o timeout [fill.go:235]

# 下载数据块太慢
<INFO>: slow request: GET chunks/6E/4/4020590_0_4194304 (%!s(<nil>), 105.068s)

确认组内成员网络互通，并且使用万兆网络。如不确定网络质量，可以使用 iperf3 等工具进行测速。

缓存组能否高速访问对象存储服务？

如果缓存组成员无法快速从对象存储上下载数据，现象与报错类似于上一小节中内网带宽受限的情况。可以降低下载并发度来尝试获得更平稳的预热体验，比如 juicefs warmup --concurrent=1。

客户端负载是否过高？

客户端负载过高，在特定情况下也能引起分布式缓存命中率低。比方说客户端启用了 --fill-group-cache 选项，将数据写入文件系统的同时，还会将数据贡献给分布式缓存集群。如果这些参与写入的客户端负载过高，虽然仍能够正常写入 JuiceFS 文件系统，但分布式缓存的写入则可能失败（缓存写入不会进行重试），而一旦失败，读取这些文件就会产生穿透到对象存储的请求，造成缓存命中率低。

资源占用过高​

如果 JuiceFS 客户端的资源占用过高，我们建议通过调整挂载选项的方式主动降低资源占用，而不是为其设置资源边界，比方说：

  • 用 systemd.service 来运行 JuiceFS 客户端
  • 用容器来运行 JuiceFS 客户端（例如通过 JuiceFS CSI 驱动，不过 CSI 驱动则是另一个话题了，参考「CSI 驱动资源优化」）

JuiceFS 文件系统作为基础设施，强行限制其资源占用，可能会导致使用体验受影响：

  • 设置 CPU 上限，则 JuiceFS 客户端进程的 CPU 用量可能受到限制（throttle），造成文件系统访问极慢甚至卡死
  • 设置内存上限，则 JuiceFS 客户端可能因为 OOM（Out of Memory）而被强制退出，进而造成挂载点丢失。即便能自动重启恢复，应用也不一定能妥善处理这种情况，比如在 hostPath 模式下使用 JuiceFS，如果 JuiceFS 客户端重启，则需要重启应用容器，才能恢复容器内的挂载点
  • 设置网络带宽上限，则 JuiceFS 客户端下载对象存储数据时可能太慢导致超时，引发 IO 错误，这点在「与对象存储通信不畅」中有详细介绍

因此如果资源占用过高，参考本节的优化手段，降低 JuiceFS 客户端资源占用。同时也要注意，资源优化势必不是免费的，也会影响性能，但相比设置资源上限，往往能获得更平稳的使用体验。

CPU 占用过高​

  • 降低 --upload-limit 和 --download-limit，限制上传、下载速度（默认无限制），主动让 JuiceFS 更慢速运行，可以在大吞吐场景下降低 CPU 占用。

内存占用过高​

  • 读写缓冲区（也就是 --buffer-size）的大小，直接与 JuiceFS 客户端内存占用相关，因此可以通过降低读写缓冲区大小来减少内存占用，但降低以后，可能同时也会对读写性能造成影响。更多详见「读写缓冲区」。
  • JuiceFS 挂载客户端是一个 Go 程序，因此也可以通过降低 GOGC（默认 100）来令 Go 在运行时执行更为激进的垃圾回收（将带来更多 CPU 消耗，甚至直接影响性能）。详见「Go Runtime」。
  • 如果你使用自建的 Ceph RADOS 作为 JuiceFS 的数据存储，可以考虑将 glibc 替换为 TCMalloc，后者有着更高效的内存管理实现，能在该场景下有效降低堆外内存占用。

数据迁移相关问题（juicefs sync）​

如果要进行数据迁移，将大量文件拷贝到 JuiceFS，我们推荐使用 juicefs sync。本节介绍常见问题的排查思路，以及相关最佳实践。

拷贝卡死、进度条没有反应

juicefs sync 进行数据拷贝时，会首先遍历源存储的所有对象，如果文件数量巨大，并且是增量拷贝，那么遍历、检查对象是否存在并跳过的过程将会花上更多时间，进度条显示写入速度为 0，但等候一阵，真正的数据拷贝便会发生。

如果数据拷贝速度不理想甚至卡死，可以通过以下手段排查：

  • 检查​「JuiceFS 客户端日志」，确保目标文件系统运行正常。如果日志中出现对象存储请求慢，或者请求错误，参考本章其他相关小节进行排查和解决。
  • 检查​「文件系统访问日志」，如果数据拷贝正常工作，那么日志中会出现大量 write 调用。
  • 为 juicefs sync 添加 --verbose 参数，打印 DEBUG 日志。
  • 如果作为目的地的 JuiceFS 文件系统并无明显异常，那么问题可能出在数据源，用合适的手段确认数据源工作正常，比如测试确认是否能正常将数据拷贝到本地文件系统。
写入速度慢

如果已经通过客户端日志定位到问题就是写入太慢，这是一些可能导致慢的原因，以及解决手段：

云主机访问公网带宽受限。对于不少云服务商，为主机绑定公网 IP 后，访问外网也将通过该 IP 对应的网卡，公网带宽往往很小（比如 10 Mbps），考虑增大带宽，或者将云主机配置成用 NAT 作为公网出口，然后为 NAT 配备更大的出口带宽。

如果你没有条件修改源数据所在的云主机出口带宽，但 VPC 下有其他的节点配备了更大的出口带宽（比如多出口 IP 的 NAT），那么可以考虑在大带宽节点上挂载 JuiceFS，然后通过 SSH 内网拷贝数据到大带宽节点的 JuiceFS 挂载目录，命令类似：

# 在大带宽节点上挂载好 JuiceFS，然后从源数据节点通过 SSH 拷贝数据
juicefs sync root@src:/data /jfs/

如果观察网卡流量，发现写入速度还没达到出口带宽，考虑增加并发度，甚至启用多机同步拷贝，详见​「数据同步」。

卸载错误​

卸载 JuiceFS 文件系统时，如果某个文件或者目录正在被使用，那么卸载将会报错（下方假设挂载点为 /jfs）：

# Linux
umount: /jfs: target is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

# macOS
Resource busy -- try 'diskutil unmount'

# 在 Kubernetes 集群中，卸载失败表现为 Mount Pod 无法删除，卡死在 Terminating 状态
# 此时 kubelet 会产生如下错误日志
Failed to remove cgroup (will retry)" error="rmdir /sys/fs/cgroup/blkio/kubepods/burstable/podxxx/xxx: device or resource busy

这种情况下可以：

  • 用类似 lsof /jfs 的命令，找出该文件系统下正在使用的文件，然后按需处置对应的进程（比如强制退出），然后再次尝试卸载。
  • 用类似 ps -eo pid,ppid,stat,command | grep ' D ' 的命令检查是否存在与 JuiceFS 相关的 D 状态（Uninterruptible Sleep）进程（比如正在访问 JuiceFS 挂载点的进程）。如果存在，需要用下方的步骤强行关闭 FUSE 连接：
    • 用 echo 1 > /sys/fs/fuse/connections/[device-number]/abort 强制关闭 FUSE 连接，然后再次尝试卸载。其中 [device-number] 也许需要你用 lsof /jfs 手动确认，不过本机只有一个 FUSE 挂载点的话，那么 /sys/fs/fuse/connections 下也只会包含一个目录，不必特意确认。
  • 如果并不关心已经打开的文件，只想要尽快卸载，也可以运行 juicefs umount --force 来强制卸载，不过注意，强制卸载在 Linux、macOS 上的行为并不一致：
    • 对 Linux 而言，juicefs umount --force 意味着 umount --lazy，文件系统会被卸载，但已打开的文件不会关闭，而是等进程退出后再退出 FUSE 客户端。
    • 对 macOS 而言，juicefs umount --force 意味着 umount -f，文件系统会被强制卸载，已打开的文件会强制关闭。
最后于 更新
Follow us on Twitter
Let's chat on Slack