Linux内核中tracefs与debugfs的区别及适用场景选型

很多人刚接触内核追踪会觉得两个文件系统功能重叠，本质是历史遗留原因导致的表象，核心差异其实非常明确：

• 定位完全不同：debugfs是内核推出的通用调试虚拟文件系统，设计目标是给所有内核子系统提供一个简单的临时调试接口出口，驱动、内存管理、文件系统、网络栈，任何子系统想抛点调试信息、加个调试开关都能往上面挂，追踪类接口最早只是debugfs里承载的一小部分内容。tracefs是内核3.19版本专门为追踪子系统拆分出来的专用虚拟文件系统，从设计之初就只承载ftrace、tracepoint、系统调用追踪、函数追踪这类追踪相关能力，不混放其他无关的调试接口。
• 安全与权限逻辑不同：debugfs默认挂载在/sys/kernel/debug路径，上面承载了大量可以直接修改内核运行状态的高权限接口，绝大多数生产环境出于安全考虑会直接禁止挂载debugfs，且默认权限完全对普通用户隔离。tracefs默认挂载在/sys/kernel/tracing路径，权限粒度更细，可以单独给追踪相关的用户组开放对应读写权限，不需要放开整个debugfs的全量敏感接口，攻击面小很多。
• 维护状态不同：现在内核主线里，追踪相关的所有新功能、新接口只会更新到tracefs下，debugfs下的tracing目录本质只是为了兼容老版本工具做的兼容层，不会再新增功能，不少新的Linux发行版已经直接移除了debugfs下的追踪兼容入口。
• 兼容性承诺不同：内核社区从来不对debugfs下的接口做稳定性保证，版本迭代时各个子系统可以随时修改、删除debugfs下的自定义接口，不会做兼容通知。而tracefs是perf、trace-cmd、ftrace等主流追踪工具的标准依赖接口，社区对它的接口兼容性约束严格很多，不会随意做破坏性变更。

• 选debugfs的场景：
  • 需求和函数追踪、事件追踪、系统调用追踪无关，只是要访问其他内核子系统挂在debugfs下的专属调试接口，比如驱动调试参数调整、内存子系统运行状态查看、文件系统内部状态统计这类需求，这类接口从来没有在tracefs上提供过。
  • 需要适配3.19以前的旧内核版本，这类版本还没合入tracefs，只能用debugfs下的追踪接口。
• 选tracefs的场景：
  • 所有和内核追踪相关的开发需求，不管是做自定义追踪工具、写内核追踪模块还是做系统可观测能力，都优先选tracefs，这是当前内核社区认可的唯一标准追踪接口入口。
  • 生产环境部署可观测、追踪能力的场景：不需要挂载全量debugfs，安全风险低，权限配置灵活，不会因为引入调试能力额外扩大系统攻击面。
  • 需要长期维护、跨内核版本兼容的追踪类工具：debugfs下的追踪兼容层后续会被逐步移除，新的追踪特性只会在tracefs上落地，用tracefs能避免后续版本升级出现接口失效的问题。

内容的提问来源于stack exchange，提问作者Franc