> 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/20180910-wang-luo/we-get-letters.md).

# 读者来信

作者：**Michael W Lucas**

嗨，FJ Letters Dude，

我应该使用哪个文件系统？

——FreeBSD 新手

亲爱的 FreeBSD 新手，

首先，欢迎来到 FreeBSD。更广泛的社区很乐意帮助你。

第二，请告诉我谁告诉你开始给我写信。我需要好好“感谢”他们。

文件系统？当然，我们来谈谈文件系统。讨论哪个文件系统最差就像比较双手剑与伐木工级链锯和工业郁金香压榨机的优点。虽然每一个都有完全合法的用途，但在新手手中，它们更可能伤害所有相关人员。无论你使用什么操作系统：FreeBSD、任何 BSD、Linux、Windows、illumos 或其他什么。文件系统都是最差的。

我是说，让我们看看内存文件系统。基本想法——取一块内存并将其用于临时存储——听起来足够合理。如今大多数非虚拟计算机都有足够的内存，可以挥霍几个 GB 用于快速的 **/tmp** 或甚至编译器临时空间。将 `poudriere` 配置为使用内存作为临时文件将大大加快你的软件包构建。

但 FreeBSD 有两种不同的内存文件系统：**mfs(5)** 和 **tmpfs(5)**。老式的 MFS 将 UFS 文件系统放在一块内存上。它很快，当然。但只要文件系统存在，MFS 使用的任何空间都不可用于其他用途。假设你用 MFS 创建一个 5 GB 的 **/tmp**，复制 4.9 GB 到它，然后擦除它。那 4.9 GB 仍然被占用。你可以通过使用 **tunefs(8)** 启用 TRIM 来指示 MFS 释放未使用的内存，但没有人费心做这个。

较新的替代方案 `tmpfs`，专门为临时文件系统设计。默认的 `tmpfs` 最大大小等于系统内存加上系统的交换空间。“你有多少内存？给我。”创建 `tmpfs` 时，请务必指定标志 `size=`。否则，小心监控 `tmpfs` 空间使用。不是你会配置你的监控系统来监视 `tmpfs`，因为它是临时的。

而且无论怎样，有一天你会忘记你把内存空间用作文件系统。你会把一些重要的东西放在那个临时空间里，然后重启。当那些重要数据消失在以太中时，你会变得非常恼火。

一些其他文件系统倒不会主动作恶。设备文件系统 **devfs(5)** 提供设备节点。不能存储用户数据的文件系统是最好的文件系统。但随后某个聪明的系统管理员决定修改 **/etc/devfs.rules** 来为其特殊应用更改标准设备节点，或 **/etc/devd.conf** 来创建或重新配置设备节点，整个系统就垮了。

说到聪明的系统管理员，人们有时决定他们想优化磁盘空间或减少需要维护的文件副本数量，方法是在系统其他地方重用分区或数据集。FreeBSD 的 **nullfs(5)** 允许你多次挂载分区，本质上回收同一块磁盘空间。使用大量 jail 的人使用只读 `nullfs` 挂载来让单个 FreeBSD 基本安装支持多个 jail。

FreeBSD 的 **unionfs(5)** 允许你合并多个文件系统。许多人成功地使用 `unionfs` 为文件系统提供自定义视图，同样是为了 jail。然而，Unionfs 也许是 FreeBSD 生态系统中最不受欢迎的文件系统。我认识几个开发者不愿接近它。我认识其他人说它完全安全。我所知道的是，备份是好的。

网络文件系统？哦拜托。专用的 6GB/s SATA 控制器总是会胜过通过千兆以太网运行的任何东西，特别是如果你使用同一个网络接口来管理主机。是的，6 GB 确实比 1 Gb 多——但这个比较还涉及字节与位的区别。你看到的是最佳吞吐量的 48 倍差异。并且永远记住，并非所有网络交换机都生来平等。我有一整堆所谓的“千兆”交换机，它们完全无法让超过四分之一千兆每秒的数据通过。

我必须承认，尽管很不情愿，FreeBSD 的新 iSCSI 栈是坚如磐石的。而 FreeBSD 的 NFS 实现是世界上最好的之一。许多人在高性能应用中使用它们……但它们仍然是网络文件系统。在生产环境中大量使用它们的人拥有顶级的网卡和名副其实的交换机。如果你在邮件列表或论坛上询问，他们会提供他们的建议。

FreeBSD 对新的 NFSv4 协议有出色的支持。虽然早期版本的 NFS 互操作得相当好，并且行为相同，但 NFSv4 是一个完全不同的野兽，具有不同的语义。在部署它之前，你真的需要做一些阅读。NFSv4 确实有一个广泛的访问控制列表系统，让你完美实现大公司 IT 部门能梦想到的最糟糕的可憎之物，所以这也算是一种本事。

你偶尔会看到进程文件系统 **procfs(5)** 的提及。许多 FreeBSD 开发者真的、真的不希望 `procfs` 存在。当我在 2018 年版的《Absolute FreeBSD》中记录了对 `procfs` 的需求时，技术审稿人 John Baldwin 重写了 **ps(1)** 使 `procfs` 不再必要。据我所知，激怒 FreeBSD 开发者最快的方法就是需要 **/proc**。

**Autofs(5)** 是为桌面用户编写的。它自动识别文件系统并为你挂载它们。如果你启用 `autofs` 并插入 USB 驱动器，驱动器上的各种分区和标签将显示为 **/media** 中的目录。进入其中一个目录将自动挂载该分区。同样，`autofs` 使 NFS 挂载点在 **/net** 中可用。列出 **/net/fileserver** 的内容显示主机 fileserver 上的所有 NFS 挂载点，进入其中一个目录会自动挂载共享。它仍然在使用网络文件系统，所以它几乎肯定以眼泪告终。

为所有 FreeBSD 文件系统辩护，我必须说：至少它们不是 EXTFS。虽然 FreeBSD 也支持 **extfs(5)**，所以这也没多大帮助。

真的，文件系统唯一明智的举动就是不玩。

FJ Letters Dude，

我的意思是我正在查看安装程序，它想知道我想使用 UFS 还是 ZFS？而 George Neville-Neil 说你需要来信。

——FreeBSD 新手

哦！

使用 ZFS，除非你不能。

作为新用户，不要在内存少于 2 GB 的系统上使用 ZFS。4 GB 或更多会更明智。不要在非 64 位平台上使用 ZFS。一些虚拟化系统在从一个主机迁移到另一个主机时没有正确标记磁盘镜像。在这样的系统上迁移的 ZFS 池不会启动。如果你在虚拟化平台上运行，在 ZFS 主机上测试迁移，然后再到处部署。

感谢你的提示。下次我遇到 GNN，我们会讨论他鼓励人的不幸倾向。

***

**MICHAEL W LUCAS** (<https://mwl.io>) 写了太多书，包括《Absolute FreeBSD》、《FreeBSD Mastery: Specialty Filesystems》和《git commit murder》。将你的问题发送到 <letters@freebsdjournal.com>。来信将按其启发、逗乐或激怒专栏作者的顺序回答，并可能出于他自己的目的而编辑。


---

# 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/20180910-wang-luo/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.
