使用profile-sync-daemon时明明有足够空间却持续触发空间不足错误

看起来你遇到的问题有点反直觉——明明tmpfs还有大把剩余空间，WhatsApp Web却一个劲提示“空间不足”。我来帮你拆解几个可能的原因，以及对应的排查方向：

• WhatsApp Web的实时写入峰值可能远超当前profile初始大小
  你看到的profile size: 191M只是psd启动时同步到tmpfs的初始文件大小，但WhatsApp Web在运行时会疯狂缓存聊天媒体（图片、视频、表情包）、会话数据，这些内容会实时写入tmpfs里的Firefox profile。旧的recovery目录有1.3G，说明你的profile在日常使用中曾膨胀到过这个规模——如果WhatsApp Web加载时瞬间写入大量数据，可能会短暂超过tmpfs的实际可用空间（虽然df -h显示还有1.8G，但系统其他进程也在占用tmpfs，实际留给Firefox的空间可能没这么多）。

• Firefox可能误检测了其他分区的空间
  有时候Firefox的磁盘空间检测逻辑会“认不清地方”：它没正确识别当前运行的profile在tmpfs上，反而去检测/home分区的剩余容量。你可以先检查下/home分区的剩余空间，如果它本身快满了，很可能会触发这个错误。另外，也可以打开Firefox的about:config，搜索browser.disk_cache.dir，确认缓存目录是否指向tmpfs里的profile路径，而不是原来/home下的旧目录。

• psd的recovery目录可能干扰了空间检测
  你的psd parse输出显示有一个1.3G的recovery目录，虽然它在/home下，但Firefox的崩溃恢复逻辑可能会扫描这个目录，误判整体可用空间。建议先尝试用psd的-c参数删除这个recovery目录，然后重启Firefox和psd，看看问题是否消失：

  psd -c
  

• tmpfs的实际可用空间可能被系统预留限制
  你把RuntimeDirectorySize设为25%，df显示tmpfs总大小2G，但系统可能会为其他用户进程预留一部分tmpfs空间，导致实际可用于Firefox的空间不足。可以尝试把这个值调大到30%甚至40%（修改/etc/systemd/logind.conf后需要重启systemd-logind服务或者直接重启系统），之后再观察是否还会触发空间错误。

备注：内容来源于stack exchange，提问作者ShankarG