由于无法卸载tmpfs，我们的开发机器在引导期间偶尔会遇到致命错误。这个周末我破获了这个案例，新零售企业应用中心，所以我想分享一下我对引导时间DTrace的使用，以及我在这个过程中遇到的操作系统发霉的角落。首先，我应该解释一下引导期间会发生什么，以及为什么要卸载tmpfs文件系统。升级和引导当您将Delphix系统从一个版本升级到下一个版本时，我们将保留您的配置。系统配置的一部分存在于SMF中，即服务管理工具，返利联盟，它存储在位于/etc/svc的文件系统中。我们将/etc/svc保存在它自己的ZFS数据集中，这样我们就可以对它进行快照和克隆以进行升级，以保存旧数据（以防需要回滚）并保留设置。这有点棘手，因为内核在/etc/svc/volatile上挂载tmpfs，以便为init（1）之类的早期进程提供暂存空间；在挂载到/etc/svc/volatile之前，我们必须先卸载/etc/svc/volatile。下面是我们的引导脚本部分的内容：##内核将tmpfs安装在/etc/svc/volatile上，因此我们需要#在/etc/svc上安装svc数据集之前卸载它。#umount/etc/svc/易失性$ZF安装/svc/F安装安装-F tmpfs/etc/svc/volatile问题EBUSY的/etc/svc/volatile的卸载偶尔会失败，但并非从未发生过。启动脚本将停止并报告错误；随后尝试卸载/etc/svc/volatile将成功。所以没什么好谈的。tmpfs代码确实揭示了这一点：静态inttmp_卸载（struct vfs*vfsp，int flag，struct cred*cr）{...tnp=tm->；tm_根节点；如果（TNTOV（tnp）->；v\u count>；1）{互斥体退出（&tm->；tm\U内容）；返回（EBY）；}对于（tnp=tnp->；TNU forw；tnp；tnp=tnp->；TNU forw）{if（（vp=TNTOV（tnp））->；v\u count>；0）{...返回（EBUSY）；}等待（vp）；}...因此，有人对文件系统的根或文件有额外的控制权。我查看了/etc/svc/volatile的内容，发现了一个文件：初始状态. 翻阅init（1）的代码后，我惊讶地发现init（1）保存了一个状态文件，其中包含了感兴趣的进程列表。它不会使文件描述符保持打开状态（这会阻止我们卸载文件系统），返利联盟，但它会不时重写文件。我担心init（1）可能与我们的脚本赛跑。我不想理解代码的残酷复杂，所以我修改了引导脚本，以执行以下操作：pstop 1停止初始化umount/etc/svc/易失性mount-F zfs$base/running/svc/etc/svc安装-F tmpfs/etc/svc/volatile修剪1继续初始化如果卸载失败，我可以使用pfiles（1）来查看init（1）是否确实在/etc/svc/volatile中打开了某些内容。我确信，在尝试观察这个问题时，我会把它赶走——一个海森堡——但是在运行了一个重启循环之后，我们发现了这个问题，init（1）没有在/etc/svc/volatile中打开任何东西。下一步…启动时间DTrace问题是，当我进入系统时，导致错误的条件已经自行解决。我想做的是在tmp_unmount（）返回EBUSY时使系统陷入恐慌，这样我就可以使用调试器进行调试器了。在许多需要在调试逻辑中编译的系统上，幸运的是启用DTrace的系统有更好的选择。我以前的同事bryancantrill发明了匿名DTrace来查看引导时间问题——在引导阶段比可以执行DTrace（1M）命令行实用程序更早。要使用引导时DTrace，请像往常一样指定D程序，但是添加-A选项以将D程序添加到DTrace内核模块的引导时配置中。重新启动后，DTrace将启用以后可以用DTrace-a检索其输出的程序。在我的例子中，当tmp_unmount（）返回EBUSY时，我想将其放入内核调试器，因此我按如下方式运行DTrace：dtrace-A-w-n'fbt:tmpfs公司：tmp公司_卸载：return/arg1==EBUSY/{panic（）；}'在多次重新启动之后，我们再次遇到问题并进入调试器。多亏了我的同事Eric Schrock在内核中放置的基础设施，我能够快速看到引用计数阻止我们卸载tmpfs的文件的标识：[5] >；FFFFFF 0197321B00:：打印vnode_t v_路径易失性路径/0x97vv0-下一个州"值得注意的是，véu路径不能保证是正确的，但可能反映了某种状态。在本例中，我检查了tmpfs的目录结构，发现文件名实际上是/etc/svc/volatile/初始状态--重命名时不更新v峎u路径。但我一辈子都搞不清是谁打开了那个档案。其他（少数）进程都没有触及该文件。我查看了fsflush代码，它将缓存的数据刷新回磁盘，但这没有太大意义，似乎也没有造成问题。除非系统内存不足，否则pageout线程不应该运行。我使用kmdb的：：kgrep命令查找引用vnode_t或其相关页的位置。有很多，我很快就迷上了虚拟机系统。我决定回到DTrace，而不是在内核的结构中卑躬屈膝。我想回答的下一个问题是：在tmp_unmount（）返回EBUSY之后，是谁发布了对tmpfs vnode_t的引用？为了回答这个问题，我写了一个D脚本：fbt:tmpfs公司：tmp公司_卸载：条目{自我->vfs=参数[0]；}fbt:tmpfs公司：tmp公司_卸载：返回/arg1==EBUSY/{GoIt=自我->vfs；}fbt:tmpfs公司：tmp公司_卸载：返回{self->vfs=空；}fbt:genunix公司：越南_rele:进入/明白了！=空参数[0]->；v\u vfsp=goit/{恐慌（）；}我安装它作为我的匿名DTrace启用，重新启动，然后等待。谁邓妮特就像神秘公司的黑帮揭穿罪犯，无助地被精心设计的陷阱抓住一样，我用内核调试器来识别子系统，结果发现它不是别人，正是无害的老Pageout先生。喘息！为什么寻呼机在运行？系统有足够的内存，所以它通常不会运行，除非在启动的很早就发生了一个异常（事实证明）。在启动后的第一秒钟，pageout将精确执行四次，以填充某些与性能相关的参数，这些参数使它能够预测将来分页内存所需的时间。当它执行时，pageout将识别出未使用的页面并暂时保留它们——这正是我们问题的根源所在！解决方案我还在研究如何解决这个问题。最简单的方法是在尝试卸载之前先睡一会儿。稍微复杂一点的是尝试在循环中卸载，直到过了一秒钟（在bash中检查$SECONDS）。更复杂的是重新考虑pageout——我仍然不完全理解它是如何工作的，大数据难学吗，但它确实似乎在做一些在过去十年里被推翻的假设，返利平台，其中包含了一个宝贵的评论：目前，这件事还很粗糙。注意，这里的"现在"指的是1987年或更早的时候——正如罗杰·福克纳所说，"它来自新泽西州。"结论要不是这些多管闲事的工具，Pageout早就得逞了！引导期间的DTrace非常棒——当您需要时，它是一个救命稻草。有些地方在引导时太早，DTrace无法帮助您；因为VProbes可以为您提供一些类似DTrace的功能。成熟的系统可能有一些发霉的角落，所以你的工具最好能胜任这项任务。