我正在创建一个与示例passthrough_fh非常相似的基于保险丝的文件系统。在调用基础系统调用之前，我在处理程序中记录了一些统计信息。
我将它与来自debboostrap的debian Wheezy chroot映像一起使用。这个想法是将wheezy /镜像到我的挂载点，然后一个进程将chroot到挂载点，并且所有活动都将通过我的保险丝fs记录。
操作系统似乎可以使用chroot很好地处理路径解析。也就是说，如果chroot进程执行stat("/bin/ls")，则从我的融合进程中看到stat("wheezy/bin/ls")。
但是我不确定如何处理符号链接。例如文件
wheezy/lib64/ld-linux-x86-64.so.2
指向
/lib/x86_64-linux-gnu/ld-2.13.so
因此，当我调用stat("wheezy/lib64/ld-linux-x86-64.so.2")时，它将无法正常工作，因为操作系统将尝试取消引用符号链接/lib/x86_64-linux-gnu/ld-2.13.so而不是正确的wheezy/lib/x86_64-linux-gnu/ld-2.13.so的引用。
这是一个简化的示例，我不能只在所有路径前加wheezy/，我还想支持不使用chroot或多次chroot的应用程序。
我可以想到一些不太理想的方法来做到这一点，例如如果使用chroot，请检查/proc/pid/root/以获取进程的根目录，但随后我必须始终检查文件是否为符号链接。
基于熔断器的文件系统是否有更好的方法或通用方法来解决此问题？
答案 0 :(得分：0)
联系保险丝开发邮件列表后，我收到以下答复：
If you are performing this stat(2) for GETATTR or LOOKUP, you should
be using lstat(2) instead. This will tell the kernel that you found a
symlink and it should keep managing path resolution correctly for you.
也就是说，在处理LOOKUP或GETATTR时使用lstat(2)，使用lstat的结果填充保险丝结构。从那里开始，内核将自动处理名称解析（甚至对于符号链接和在chroot中运行的进程）。