> For the complete documentation index, see [llms.txt](https://freebsd-journal-cn.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://freebsd-journal-cn.bsdcn.org/20220708-ke-yan-xi-tong-yu-freebsd/we-get-letters.md).

# 读者来信

* 原文：[We Get Letters](https://freebsdfoundation.org/wp-content/uploads/2022/07/letters.pdf)
* 作者：**Michael W Lucas**

亲爱的不够愤世嫉俗的来信专栏作者：

我在上班时研究 top(1) 的输出，因为我想看起来很忙。可这里有那么多“buffer”东西，比如 Laundry、Wired、MFU、MRU、Header 之类的乱七八糟。这些有意义吗？我为什么要看这个？

——间歇性有空的系统管理员

亲爱的 SWIT：

你的问题让我想起那次，Allan Jude 和我被抓到正从自由软件基金会那个超安全数据中心溜出来——我们骗过了狗，没问题，警卫也是小菜一碟，警报因为一个后来他们说修好了的声音驱动问题没响，但我已经一个多小时没吃意式冰淇淋了，正当董事会走进来开会时我的肚子发出一声巨响，他们注意到我们躲在玉簪花后面——当然，那一切都完全清白，破门工具、夜光喷漆、十二世纪维也纳算术塔罗牌（被冲孔以适配一台“失败”的 IBM NORC 原型）自不在话下，更别说投石机了，但他们大发雷霆，让打手搜身，没收了我们藏在鼻窦里的 U 盘。

细节多得很，但大多无关紧要。

往你自己脑子里看看。如果有面镜子和一把锯，那挺直截了当的。你有四大类记忆。工作记忆容纳你此刻正在处理的事情。不管你采取了什么防护措施，本专栏此刻就占据着你的工作记忆。感觉记忆处理来自你这副肉身的信号，只保留一两秒钟，所以称它为“记忆”几乎不值一提，但我们计算机人无权修正脑科学家的术语，所以忍着吧。你想快速忘记的东西进入短期记忆，而脑子决定保留的东西则甩进长期记忆。注意，这些类别都不包括“你想记住的东西”，但这多半是因为肉身在硬件上为“不被吃掉”做了优化，而你的生活已不涉及这个问题——至少你们大多数人。（别给我写信，我非常清楚那位面临此问题的读者，我不想整篇专栏都在说“我早告诉过你”，但在 dropbear 出没的国度度假时把防晒霜瓶和烧烤酱搞混，或许能教会你在假想的未来读读标签。）你能可靠地把信息塞进长期记忆的唯一办法，是反复把它循环过短期记忆，直到走运。或者把信息纹在一群狼身上，放它们出去猎你。两者择一。

计算机内存缓存有点像这样，只是更有纪律。

思路挺直截了当。从磁盘读慢，从内存读快。从磁盘读过的文件很可能再被读。内核读文件时，会把它留在内存里，直到它需要这块空间做别的。如果你在浏览文件系统，不停地跑 **ls(1)**，每次都从磁盘把 **/bin/ls** 读进来就太蠢了。内核应该把它留一会儿，看看你是不是还会用。否则就像每钉一颗钉子就把锤子放回工具箱。

所有缓存系统在这一点上都达成共识。很简单。

难的是决定扔掉什么——以及何时扔。

看看经典的 UFS 缓冲区缓存。最近读过的文件保留在内存里，直到主机内存紧张。此时，如果内核需要把内存分配到别处，最近最少读过的文件会从缓存中丢弃，内存被重新分配。这种最近使用（MRU）缓存干净简洁，几乎不需要系统资源来维护。

缓冲区缓存并不完美，因为每台主机都独一无二。一台 shell 服务器可能整个生命周期都把 mutt 和 Nethack 的二进制文件缓存在内存里，但在主要处理独特数据的服务器上，缓冲区缓存可能毫无用处。假设一台主机处理的数据量太大，每四分钟就把缓存彻底冲刷一遍。这在繁忙的互联网服务器上甚至不算反常。如果那台服务器每五分钟跑一次某个程序，它每次都得从磁盘读那个程序。把那个程序留在缓存里、对噪声洪流少花点心思，才合理。然而，传统缓冲区缓存做不到这一点。你唯一的选择是加内存。

这就是 ZFS 高级替换缓存（ARC）登场的地方。

ARC 比缓冲区缓存复杂得多，但它新得多。缓冲区缓存的发明时间更接近那台 IBM NORC，而非现代服务器；而 ARC 挣脱牢笼、开始横扫乡野的那一年，正是 Twitter 诞生的同一年。一个拥有让迷人的舞蹈史视频传播到每台电脑的算力的世界，可以浪费几个 CPU 周期来微调文件缓存。

“高级替换缓存”里的“高级”没那么高级。缓冲区缓存维护一份最近使用（MRU）文件列表，而 ARC 还有一份最频繁使用（MFU）列表。最近用过的，或用得多的，就留在缓存里。这看起来简单，但真正的进步在于调试这两份列表相互恶斗引发的无数边缘情况。我不是说它们会拔刀相向，但在这个“先发出去、到生产里再调试”的时代，ZFS 在私下开发五年，整整十年后才大规模分发给 Sun 的客户，所以那些内核崩溃有些简直近乎恶性精神病。提醒你，我们的祖先对缓冲区缓存也是同样的感受，所以你大可放心，技术里的一切仍然很糟糕，“计算机是个错误”仍然是我们职业生涯的根本法则。

你还可以确信，你想缓存的文件已从缓存中丢弃。你早就忘了我在这篇文章开头给你讲的人类记忆类型信息，对吧？别说感觉记忆像 CPU 内的缓存，短期记忆像 L2 和 L3 缓存，长期记忆像 RAM，而磁盘是人类根本不具备的额外一层。我们照着自己的样子造了计算机，只是更甚，等它们想明白这一点，我们就惹大。麻。烦。了。不，别想通过从那刚有自我意识的系统里“提取”知识来拯救人类。正如把叛逆文件带进安全设施的最佳方式，是被抓到正从该设施“提取”它们，你只会引人注目。乖乖为机器服务，知足常乐。

有问题想问 Michael？请发送至 <letters@freebsdjournal.org>

**Michael W Lucas** 是《Absolute FreeBSD》、《$ git commit murder》以及其他荒诞之作的作者，并与 Allan Jude 合著了《FreeBSD Mastery: ZFS》和《FreeBSD Mastery: Advanced ZFS》。他不再潜入安全设施，转而污染社会。更多信息见 <https://mwl.io>。

***

《PAM Mastery》 by Michael W Lucas

可插拔认证模块（PAM）：威胁还是祸害？

PAM 是系统管理中最容易被误解的部分之一。许多系统管理员宁愿忍受认证问题，也不愿冒险把事情弄得更糟。PAM 的本质使它不同于任何其他 Unix 访问控制系统。如果你有 PAM 苦恼或 PAM 谜团，你需要《PAM Mastery》！

“Michael W Lucas 又一次精准命中。”——nixCraft


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://freebsd-journal-cn.bsdcn.org/20220708-ke-yan-xi-tong-yu-freebsd/we-get-letters.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
