Tilnel's Blog

Preface-一月十三日

2099-12-31T15:59:59.000Z

新年写博客发现读者使我变得拘束。之后会加大力度锐评。

祝读博客的朋友都永远健康永远快乐永远不死永远爽。

Tilnel 2026-01-13

第三版置顶

第二版置顶

第一版置顶

DetSim for Go runtime

2026-04-01T16:00:00.000Z

在 go 程序启动时，state_initialize 的过程中，试图从程序的真实入口点（对于 libc 来说，是 _start）推进到 main 之前的部分，调用 extract_one_syscall 的时候。在 waitpid 的时候，并没有停在 sigtrap | 0x80。

我使用 strace 来观察 loop 的输出，得到它实际上在 clone 了一个线程之后，收到了 SIGURG，并且 si_code=SI_TKILL。这可能与 go 的 runtime 有关。这似乎是某种抢占式调度设计。我尝试了在 extract syscall 的过程中禁止新线程创建，不过 go runtime 并没有允许我这样做，而是抛出了一个 exception。感觉已经万策尽了。

现在我们的解决办法，似乎只有这样：在所有 ptrace_syscall 调用后的 wait，额外处理 sigurg。

理论上，我们拥有实现“伪多线程”的可能性。也就是允许 runtime 执行这次 clone，但是我们做这样一件事：在 clone 调用时，为它的 flags 加上一个 CLONE_PTRACE。这样在 clone 之后，新线程理论上直接被我们自动 attach 并处于静止状态。然后我们再也不调度这个新线程执行，只调度主线程即可。

另外目前的 detsim 似乎还没能够识别到 go 程序从初始化到进入用户代码的那一步。已知在 go 的 runtime init 就会调用一次clone，那么 sigurg 实际上在init 时就已经在不断发送了。我们可能需要在 state_initialization 的时候，考虑到这一部分。状态初始化应该把程序推进到用户代码的前一个系统调用，但目前似乎没有这种明确的标志。我看到，在 loop程序中，go在实际执行 write hello 之前，先做了： mmap(null, 256KB, RW, private + anon), fcntl(1, f_getfl), fcntl(2, f_getfl)。

我们大概可以打包这三条作为进入用户代码前的关键系统调用识别。就像静态 C 的 mprotect 和动态 C 的 munmap 一样。（这个逻辑在 init_tracee_state 中被处理，它通过分析 elf 来设置一个初始化过程的 stop_nr. 这个判断机制大概应当被扩展）。

TCP 面试题（困难版）

2026-03-30T16:00:00.000Z

准备了一些关于 TCP 协议的题，如果都做对了就没有人比你更懂 TCP。

参考资料：RFC793 RFC1122 RFC2525 RFC5961 RFC9293

1、TCP 连接建立后，如果 peer 直接死掉了会怎么样

如果双方的 sequence 同步了，并且没有开 TCP_KEEPALIVE，并且没有后续操作，那就不会怎么样。

如果对方不能重启，后续的 send 就不断 TIMEOUT，最后达到最大重传次数，reset。

如果对方重启，后续的 send 在对端没有匹配的 socket，直接返回 RST。

2、TCP KEEPALIVE 是什么？

是 sequence - 1，长度应当为 1 的试探报文。发送一个旧的字节试探 peer 活性，不占用序列号，不影响已有消息传输。

3、哪些报文占用序列号？

SYN 和 FIN 标志都要占用 1 个序列号。text 占用与长度相当的序列号。

4、握手的目的是什么？

传统回答：确认己方和对方的传输能力。

我的回答：还能够同步双方的序列号。第一次握手告诉对方我的序列号是什么。第二次握手告诉对方序列号已获知，并同步己方序列号。第三次握手对方确认获知我的序列号。

5、如果一方在并非全部消息被接收的情况下，想要主动断开连接，应当怎么做？

分情况：1、kernel 底层未收到对方消息的 segment。此时上层应用已读取完内核缓冲区的数据。此时首先发送 FIN，不会再发送字节。但允许对方继续发送。此时如果对方发送，就进入下一个情况。

2、kernel 已收到对方消息的 segment 并放入缓冲区，但上层应用决定直接退出。此时发送 RST，不会再接收任何消息。对方收到之后，也不会再继续发送。

6、close(sockfd) 和 shutdown(sockfd, how) 有什么区别？

与上一题相关。close 在任何情况下都会断开连接，因为底层文件描述符也被关闭。如果恰好收取完所有缓冲数据，则进入 5.1。如果未收取完，则进入 5.2

shutdown 则有 SHUT_WR SHUT_RD SHUT_RDWR 选项。但是它不会关闭文件描述符。也就是说缓冲区将被保留。如果缓冲区里有东西，那么还有继续被上层读的可能。如果以 RDWR 方式关闭，则仅保留文件描述符，但与 close 无异。如果以 RD 方式关闭，则保留写端。如果以 WR 方式关闭，则发送 FIN（因为保留了读方式），这个方式与 TCP 的协议 close 是最接近的。

7、常用的 tcpdump 为什么总是看到校验码不对？

因为校验码计算可以被 offload 给网络设备。发送出去的消息在到达 kernel 后即被 TCP dump 捕获。此时校验并未计算。待发出时由网卡计算。

8、TCP SYN SENT 状态下，如果收到一个ACK号对不上己方 SYN 的 SYNACK，应当如何？

发送 RST。我们认为这是一次失败的连接。

9、TCP_ESTABLISHED 状态下，如果收到一个 SYN，且序列号不正确，应当如何？

保活，并发送 challenge ACK。首先善意假设是对端重启，那么 challenge 的 seq 与对端的新状态不匹配迫使对方发送 RST 彻底清除这个旧连接。如果对端没出问题，这是攻击者发送的虚假报文。如果 challenge 还是路由到对端，那么对端只会认为这是冗余 ACK，连接得以保活，不会因为恶意的 SYN 模拟攻击而断连。如果 challenge 路由到攻击者，那么这种攻击不是传输层能处理的。

如果序列号正确，其实也是这样干。

challenge ACK 其实就是普通的 ACK。只不过这个场景下触发对端裁决，所以叫做 challenge。

10、如果某一方以相同的序列号，发送了不同数据的 segment，应该怎么办？

未定义。由实现定义是否拒绝这种不安全的发送。实践上，在看到相同序列号之后就扔掉了，根本不会比较。

11、TCP 的关闭流程有很多很多状态。阐述它们的不同：

FIN-WAIT1 FIN-WAIT2 CLOSE-WAIT CLOSING LAST_ACK TIME-WAIT CLOSED

简而言之，是处在握手阶段的不同，以及双方消息序的交错导致的。假设有一对处于 ESTABLISHED 状态的连接两端。

A 发送第一个 FIN-ACK 进入 FIN-WAIT1、
- 如果 B 收到，则发送 ACK 进入 CLOSE-WAIT
  - 如果 A 再收到 ACK，进入 FIN-WAIT2
    - 如果这时 B 关闭，发送出 FIN-ACK，则进入 LAST-ACK
      - 如果 A 收到 FIN-ACK 则发送 ACK 进入 TIME-WAIT
        如果 B 再收到 ACK 则直接关闭进入 CLOSED
- 如果 B 没收到时刚好也 close 了，则发送 FIN-ACK 进入 FIN-WAIT1
  - 如果此时 A 收到 B 的 FIN-ACK 则发送 ACK 进入 CLOSING
    - 如果此时再收到 B 的 ACK 则进入 TIME-WAIT
  - 如果此时 B 收到 A 的 FIN-ACK 则发送 ACK 进入 CLOSING
    - 如果此时再收到 A 的 ACK 则进入 TIME-WAIT

TIME-WAIT 统一 timeout 后进入 CLOSED。

本质上是 FIN-ACK-FIN-ACK 和 FIN-FIN-ACK-ACK 的区别。

12、TCP 一端调用 accept() 之前，连接建立了吗？

建立了。如果一端 listen 另一端 connect，不管这边是否 accept，连接都已经建立了，三次握手都会完成。accept 只决定了应用程序是否处理这个已经建立好的连接。

accept，本质上只是 BSD api 对协议的适配层而不是协议的一部分。

13、TCP 双方同时向对方发起连接，会发生什么？

如果时间上赶得巧的话，两边同时发送 SYN。再互相发送 SYN-ACK。虽然是奇怪的四次握手并且没有纯 ACK。但是连接正常建立。这是协议的一部分。

提问

2026-03-14T16:00:00.000Z

本来调程序快调睡着了，冷不丁 agent 抛了个问题给我吓醒了。

play with Kimi-Code

2026-03-04T16:00:00.000Z

为了方便和 Agent 交互，我计划给 Kimi-Code 接入 TTS/STT。当然不是自己来做，而是把一个宏观的需求丢给 Agent，然后让它自己逐级展开，自己实现：

项目是复杂的，而我只能罗里吧嗦地向 Kimi-Cli 键入一堆模糊的想法。将一团模糊的东西表达清楚实在是太困难了，而 AI 似乎恰好有这个能力从我的语言中提取有用的内容，并且能归纳成一些凝练的表达。如果有更高效的输入手段，我就可以敞开来讲，事无巨细地把自己的碎片知识喂给 AI，让它理解。希望这玩意能做出来一个可用的版本。

22：47：06

现在页面上的功能几乎都无法使用，我甚至都无从说起了。除了能打开文件以外，其他的一言
难尽。首先打开项目之后根目录应该切换到项目，这是最基础的吧。然后聊天框不能发送消息，点麦克风却永远不允许使用，网页也不弹申请使用。我在浏览器里只能选择允许网站询问，但是下次点也还是不询问。浅色模式编辑器却不是浅色；终端也不靠谱。显示 terminal connected 却连接不上。最后，这个网站根本就还没有登录页面。。。

也许从零开始写一个比较大的项目还是比较困难。

23：10：25

已经有点人样了。可以语音可以会话，不过现在项目打不开，代码也不显示了。

23：49：08

被 AI 阴阳了。

00：02：54

还没开始测试如果对文件进行变更会怎么样。但是至少目前浏览项目是非常好用了。

02：13：09

测试了一下，写东西好像没啥问题。有一个小毛病就是，如果 agent 因为网络原因中止了，这阶段的流式输出都会消失。

在搞了一些奇怪的 TTS 之后，和豆包聊了10分钟天，决定直接接豆包。

在接入了豆包的 ASR 和 TTS 之后，在中间其实是 agent 的情况下，整体回复延迟变得比较高。由于是 vibe 的产物，目前 bug 比较多，并且并不灵敏的 VAD 会导致火山引擎余额-8000。谨慎配置：

repo: VIBER

坏孩子

2026-02-20T16:00:00.000Z

L 君是我在高中一位要好的同学。开篇提到他没有什么特别的理由，只是因为我写作前酝酿与思索了好久，并在一瞬间感到，自己在保持冷静这件事情上、也许是保持冷酷这件事情上，才刚刚达到他的十分之一。但这也算是灵光乍现了。事实上为了写这篇文字，我还有很多准备工作没有做好，但这些事情让我犹豫迟疑，让我心生恐惧。我所恐惧的不过是发觉自己仍然像以前那样情绪化，不能自已，口无遮拦。所以我决定，还是不要将自己置于情绪激发的风险中。

人都是矛盾的。一个人的头脑里面必然容得下两种完全相反的想法，这个冲突发生的点就是人的思想活动之所依附的位置。如果脑子里面没有矛盾了，一个人的思想活动也就停止了。眼睛一睁，世界涌入感官中与一时认识的静止是矛盾；眼睛一闭，理性的片面性又会自动产生矛盾。既然一生的思想也是由矛盾来驱动，那么一时的行为也不可能只具有单一的取向，而是由一个人自身思想的复杂性决定的。倘若一个人并不知道自己未来要怎么样，那只是因为这种复杂性超过了任何的意向，那样的思维当中包容了更多的矛盾，允许更多潜在的道路。

这种人如果受到外力的影响，要祂们在心中掐灭一种念头，消除一种可能性。表面上看是都可以接受，所以要选一个也无所谓。但实际上使祂们满意的不是选项是否合意，而是保留诸选项的权力。如果有人作势要迫使祂选择，实际上是一种对自主权的威胁，那我们知道哈基米不舒服会自己哈气的，这个时候祂就呈现出逃避或是歇斯底里的状态。与之相对的，如果一个人在某方面已经确定好了一个方向，此时却还要取消这个方向，那么结果只有抵抗，无非是消极抵抗、彻底放弃与积极抵抗、作困兽之斗的区别。

对 kernel 中的 TCP 实现进行基于模型的测试(Model Based Testing)

2026-02-07T16:00:00.000Z

提问于 2025-08-16。最终做了一个较为简化的原型程序，测得结果参见 FreeBSD TCP 的两个问题。暂未开源，开源计划未知。思路供参考。
另误打误撞发现 Linux TCP 可能存在一处与重传超时有关的 Data Race 问题，但并未验明。有兴趣可以联系讨论。

我问了 Gemini 这个问题，光是问题就阐述得很长。

#问题

我现在正在做对 TCP 协议实现的验证功能。我的做法是这样的：先根据 RFC793/RFC9293 的描述，构建一套 TCP 协议的连接状态转移的 spec，可以理解为一个状态机；然后从这套状态机出发，生成状态转移中发生的事件，包括用户调用、消息收发。具体参考 RFC793 的 EventProcess 部分，有 Listen, Connect, Send, Recv, Shutdown, SegmentArrive(Close/Listen/SynSent/SynReceived/Established/FinWait1/…)，TimeWaitTimeout, RetransmissionTimeout 等等。

状态机的状态，总体来说是一对 Socket 的状态，包括它们各自的 TCP 状态（CLOSE, LISTEN, ESTABLISHED, FINWAIT1, CLOSEWAIT 等），重传队列，segment receive buffer，stream receive buffer，send buffer，以及传输控制块（snd.nxt, snd.una, rcv.nxt，etc）

由此，事件还会进一步细化为以下的类型：

server call invoke
server call return
client send segment
client receive segment

目前，我对 TCP 的建模已经完成，它可以随机地在状态机中游走，生成序列。现在我将它与现实的 TCP 实现进行比较，目前在 linux TCP 上做实验。我的比较方式是这样的。首先有一端是 linux TCP 实现端，称为 server，另一端是测试框架端，称为 client。我按顺序处理状态机生成的序列：

如果事件是在 server 上发生，则
- 如果是 Call invoke 事件，则让server 进行对应的调用；
- 如果是 Call return 事件，则等待直到 server 的调用返回。
如果事件是在 client 上发生，则
- 如果是 Send segment，则发送对应的 segment
- 如果是 Receive segment，则等待对应的 segment 到来然后返回

client 通过 RAW socket 直接构造 IP datagram 进行发送，并接受 tcp server 端的 datagram并解析。

这一套机制目前能够勉强运转，其核心问题在于 linux TCP 对于事件的处理带有一定的不确定性，最终导致 client 端有可能在 receive segment 时接收不到期待的 segment。譬如 linux TCP 可能会根据延迟、窗口等不明确的具体运行时的变量，自行决定多个 send call 是否被合并作一个 segment 处理；或是在 client 卡着 ACK 不发送的情况下，linux TCP 会在 send() usercall 调用成功的同时，依然只对之前未确认的 segment 进行重传。

事实上就是，我的 model/状态机几乎不可能与真实的事件序列严格匹配。

目前有模糊的想法，即在某些情况下把 Linux TCP 产生的真实 segment 输入到状态机当中，再进行下一步的生成。但这似乎违背了初衷：初衷是对 TCP 协议的行为进行验证；这样做相当于直接接受了 TCP 实现产生的行为是正确的。

希望从以下几个可能的方面得到解惑：

1、是否可以在一定程度上控制 linux TCP 的行为，使其符合生成的 trace？比如对于每一个 send 调用，其内容永远不被合并到一个 segment 发送？

2、是否可以通过模糊的方式进行 segment 的匹配，使得这样的对比序列的方式至少可以执行下去？

3、如果说把 linux TCP 产生的真实 segment 输入到状态机当中，那么在什么情况下可以这样做，使得我的验证框架能够保留一定的验证能力？

#回答

您好，您提出的问题非常专业且切中要害，是进行网络协议一致性测试时必然会遇到的核心挑战：如何处理规范（Spec/Model）的确定性与现实实现（Implementation）的非确定性之间的鸿沟。

您的测试框架设计思路非常清晰，即基于模型（状态机）生成测试序列，然后通过一个测试驱动（Test Driver）来执行和观察真实系统的响应，这在测试领域被称为“Model-Based Testing”。您遇到的问题是这个领域的经典问题。

下面我将针对您提出的三个问题，结合协议测试的理论与实践，为您提供一些深入的解答和建议。

#1. 是否可以在一定程度上控制 Linux TCP 的行为，使其符合生成的 trace？

是的，可以在一定程度上“驯服”Linux TCP 的行为，减少其不确定性，使其更接近一个理想化的模型。但这无法做到 100% 的控制。以下是一些关键的控制手段：

#a. 控制 Segment 的合并（Nagle 算法）

您提到的“多个 send call 是否被合并作一个 segment 处理”主要是由 Nagle 算法导致的。您可以通过设置 socket 选项来禁用它：

TCP_NODELAY: 这是最直接的方法。在一个 socket上设置 TCP_NODELAY 选项后，send() 或 write() 系统调用会尝试立即将数据包发送出去，而不会等待之前的小数据包被对端 ACK。
- 用法: 在您的 server 端代码中，对 accept 后的新 socket 设置此选项。
- 效果: 设置后，每次 send() 调用（如果数据量小于 MSS）通常会对应一个独立的 TCP Segment。这可以极大地提高您的模型与实现行为的一致性。

#b. 控制 ACK 的发送时机（Delayed ACK）

Linux TCP 默认会启用延迟确认（Delayed ACK），即收到数据后不会立即发送 ACK，而是会等待一小段时间（例如 40ms），期望能将 ACK 和它自己要发送的数据“捎带”在一个 Segment 中。这会影响您在 client 端 Receive segment 的时机。

TCP_QUICKACK: 这个 socket 选项可以用来临时禁用 Delayed ACK。
- 用法: 调用 setsockopt 设置 TCP_QUICKACK 为 1 后，内核会立即发送一个 ACK。但请注意，这个选项是临时的，它会在下一次收到数据后被内核重置。因此，如果您希望每次收到数据都立即 ACK，您需要在每次 recv() 之后都重新设置 TCP_QUICKACK。
- 效果: 这使得您可以更精确地控制 ACK 的时序，让 server 端的行为更容易预测。

#c. 控制 TCP Segmentation Offload (TSO/GSO)

即使禁用了 Nagle，一个非常大的 send() 调用（大于 MSS）依然会被 TCP 协议栈分割成多个 Segments。更底层地，网卡驱动还可能有 TSO/GSO (Generic Segmentation Offload) 功能，即协议栈将一个大的数据块传给网卡，由网卡硬件来负责切分成 TCP Segment。

控制方法:
1. 应用层控制: 在您的测试用例生成中，确保每次 send() 调用的数据量都小于路径的 MSS (Maximum Segment Size)。这样可以避免 TCP 主动分片。
2. 系统级控制: 可以通过 ethtool 命令关闭网卡的 TSO/GSO 功能 (ethtool -K tso off gso off)。这在测试环境中是可行的，能确保分片行为完全由内核 TCP 协议栈控制。

#d. 控制重传超时 (RTO)

重传行为由 RTO 决定，而 RTO 是根据动态变化的 RTT（Round-Trip Time）计算的。在测试环境中，可以尝试固定 RTO 来减少不确定性。

控制方法: 这通常比较困难，但可以通过 ip route 命令为特定路由设置固定的 RTT 和 RTO 初始值。例如： ip route change 192.168.1.0/24 dev eth0 rtt 10ms rto_min 20ms 这需要 root 权限，并且仅在受控的网络环境中有效。

小结: 通过组合使用 TCP_NODELAY、TCP_QUICKACK、控制发送数据大小以及在测试环境中关闭 TSO/GSO，您可以显著降低 Linux TCP 的行为不确定性，让您的 trace 匹配成功率大大提高。

#2. 是否可以通过模糊的方式进行 segment 的匹配？

完全正确，模糊匹配（Fuzzy Matching）或者说基于属性的匹配（Property-Based Matching）是解决这个问题的正道。与其期待一个完全一致的 Segment，不如验证收到的 Segment 是否满足“某些关键属性”。

您的 Receive segment 事件不应该等待一个字节完全相同的 Segment，而应该等待一个满足特定条件的 Segment。

#a. 匹配什么，忽略什么？

必须严格匹配的:
- 关键控制位 (Flags): SYN, FIN, RST。这些标志直接定义了连接状态的转移，必须精确匹配。
- ACK 确认号 (ack_seq): ack_seq 必须准确地确认了 client 发送的最后一个字节。这是协议正确性的核心。
需要模糊匹配的:
- 序列号和数据 (seq 和 payload): 当期待数据时，不应期待一个特定 seq 和 len 的包。而应该维护一个“期望接收的数据流窗口”，例如 [rcv.nxt, rcv.nxt + rcv.wnd)。收到的任何 Segment，只要其数据范围 [seg.seq, seg.seq + seg.len) 在这个窗口内，并且是顺序的，就应该被接受。
- 实现方式: client 端需要自己实现一个简化的接收缓冲区（Stream Receive Buffer）。当收到一个数据包时，将其放入缓冲区，然后检查缓冲区中是否已经凑齐了模型所期望的下一个应用层数据块（例如，一个完整的 send 调用对应的数据）。
应该忽略的:
- 窗口大小 (window_size): 除非您正在专门测试流量控制，否则窗口大小是动态变化的，不应作为匹配的刚性条件。
- TCP 选项 (Options): 像 Timestamps, SACK 等选项，其具体值是高度动态的，除非测试目标是这些选项本身，否则应该忽略其具体值，只检查其是否存在即可。
- 源端口号 (Source Port): 对于 server 发来的包，源端口是固定的。但对于 client 来说，它无关紧要。

#b. 示例：

假设您的模型生成了如下序列：

server: send("hello") -> 期待 server 发送一个带 “hello” 的包。
server: send("world") -> 期待 server 发送一个带 “world” 的包。

传统的严格匹配会失败，因为 Linux TCP 可能会发出一个包含 “helloworld” 的包。

模糊匹配的做法:

模型生成 server: send("hello")。测试驱动调用 send(sock, "hello", 5)。
Client 的 Receive segment 事件不再是“等待一个 seq=X, len=5, data='hello' 的包”，而是“等待凑齐’hello’这段数据”。
Client 开始接收。它可能会收到一个 seq=X, len=10, data='helloworld' 的包。
Client 的匹配逻辑检查：
- 收到的数据 helloworld 的前 5 个字节是 hello。匹配成功！
- 将 helloworld 存入 client 的接收缓冲区。
- 此时，第一个 Receive 事件完成。
模型继续生成 server: send("world")。
Client 的 Receive segment 事件现在是“等待凑齐’world’这段数据”。
Client 检查其接收缓冲区，发现 world 已经存在。于是，这个 Receive 事件也立即完成。

这种方式将匹配的粒度从单个网络包（Segment）提升到了应用层的数据块（Stream），这与 TCP 的本质（流式协议）是相符的。

#3. 如果把 Linux TCP 产生的真实 segment 输入到状态机当中，如何保留验证能力？

这是非常高级且有效的测试思想，通常被称为**在线测试（On-the-fly Testing）**或**运行时监控（Runtime Monitoring）**。您完全没有违背初衷，反而让您的验证框架变得更加强大和实用。

关键思想是：您的模型不应再作为测试用例的“生成器”，而应作为真实系统行为的“裁决者”或“预言机”（Oracle）。

#a. 工作流程的转变：

从“生成-执行”到“引导-观察-验证”:
- 引导 (Guide): 您的模型不再生成一个严格的事件序列。而是根据当前状态，告诉测试框架：“现在，一个合法的外部事件可以是用户调用send()，或者收到一个ACK包，或者重传计时器超时”。它提供一个合法输入/事件的集合。
- 执行 (Act): 测试框架从这个合法集合中选择一个事件来执行。例如，选择 用户调用send()，于是就去调用 Linux server 的 send()。
- 观察 (Observe): 测试框架捕获 Linux TCP 产生的真实输出（一个或多个 TCP Segments）。
- 验证 (Verify):
  1. 将观察到的真实输出（如收到的 Segment S’）作为输入，喂给您的状态机模型。
  2. 模型进行状态转移。
  3. 核心验证点：
    - 合法性检查 (Legality Check): 在模型当前的状态下，接收到 Segment S’ 是否是一个合法的、允许的转移？如果模型认为在当前状态下根本不应该收到这样的包（例如，在一个已经收到 FIN 的连接上收到了新的数据包），那么您就发现了一个协议实现缺陷。这就是验证能力所在！
    - 状态一致性检查 (State Consistency Check): 转移后，模型的新状态是否满足协议的不变量（Invariants）？例如，snd.una <= snd.nxt 是否依然成立？各种缓冲区的状态是否逻辑自洽？

#b. 这种方式的优势：

拥抱不确定性: 它不再试图消除不确定性，而是将其作为测试的一部分。无论 Linux TCP 因为什么内部原因（调度、负载等）选择发送这个包而不是那个包，只要它发送的包是符合 RFC 规范的，测试就会继续。
更强的发现能力: 这种方法可以探索到更多由静态序列生成无法覆盖的、由真实系统动态行为触发的边缘状态和路径。如果 Linux TCP 产生了一个模型完全没预料到的合法行为，您的模型会学习并跟随这条路径，继续进行验证。如果它产生了一个不合法的行为，测试就会立即失败并报告错误。
解决了同步问题: 由于模型的状态总是由真实系统的输出驱动更新的，两者之间始终保持同步，避免了 trace 分歧导致测试无法继续的问题。

结论: 您应该大胆地采用这种方法。它并没有削弱您的验证能力，而是将验证的焦点从“你是否严格按照我写的剧本演？”（Trace a a’ la Trace B）转移到了“你的每一个即兴表演是否都符合戏剧（RFC）的基本规则？”（Is Action a’ valid in State S?）。后者显然是一种更深刻、更有效的验证。

希望以上分析能为您提供清晰的思路和方向。您的项目非常有价值，祝您成功！

死是凉爽的夏夜

2026-02-07T16:00:00.000Z

死不可怕，死是凉爽的夏夜，可供人无忧地安眠。 ——曹操（陈建斌饰） of 新三国

本月刚开始，我几乎要把折棒的新三国吐槽二百多期刷完了。这句话其实是海涅的诗，不过从新三国曹大佐嘴里说出来也许是天意使然，我想我也只能释然了。看来如果我无忧地安眠，那我可能死了，也可能活着，也就是生死不明，那就是死了。死在这南京城，不愧是中原第一雄关，我看比徐州城要雄壮十倍，如饮美酒，使人陶醉，不由得当浮一大白，若是不浮，我真是枉为我自己啊。毕竟酒是老英雄，越喝越奋勇，喝完之后，即使不说出吾名，也能吓你一跳。但记住不要愤怒，因为愤怒会降低你的智慧。败了又能如何，败兵必哀而哀兵必胜，只要三军听令，随我接战，战至最后一刻，就可自刎归天。

Music: 关羽之歌每日释怀，接着奏乐

以上为纯犯病硬玩梗部分，毕竟新三国很难说有什么人类成分。

穿过一场雪

2026-02-06T16:00:00.000Z

掰着指头数数，南京的冬天已经不剩下几天。成天躺在宿舍奇思妙想只会心里止不住地发毛，于是开着自动驾驶模式出门。说实话完全不知道这个点还能去哪里，但既然是自动驾驶，只要不停在路口选一个喜欢的方向就好了。

走出宿舍大门，发现天气预报的湿雪已如期而至，好在帽子、手套、防雨衣装备齐全，便懒得回头取伞来。

出学校一路向西，风大作，接得一脸雨雪。迎风走深感衣服单薄，更紧要的是头被冷风吹得有点晕乎乎的。我想如果这样在外面走几小时，是不是会落到失温的境地，不觉脚下加速想要多产生点热量。眼前是没有尽头的仙林大道，两侧有树，树以外除了河湖就是草地，须到下一个地铁站才能看到建筑，眼看着想躲也无处可躲。

每走一段，都需抖一抖身上的雨雪，以免在身上融化吸掉更多的热量。湿雪并不和人讲任何道理，只是依附在外衣上，任凭你甩甩胳膊，还是跳动几下，都不为所动。只有拽着衣襟猛地摇晃摇晃才行，冷空气就借此大举进攻，庆幸南京才将将零度。

一路上不管怎么看，都只有我一个行人。余下的都是下班的或是送外卖的电动车。仙林大道本就不适合人行，这种天气压马路的主意也就只有我开着自动驾驶模式才能想得出来。

走过羊山湖再往前有个商场，此时出现在眼前就像在游戏里到达了安全屋。走进一扇小门是电梯间，地上铺着地毯。脱下外衣郑重地抖了抖，再套在身上走进去。空调一吹感到身上很暖和，脸上甚至已经有点发烫，想必一定红扑扑的。

如果此时能蜷着身睡下就好了。

如何买衣服

2026-01-27T16:00:00.000Z

购物车里积攒了大量想买的衣服，但并非每件都是合理的选择。如果随着个人喜好的话，容易动不动就购买许多定位相同的单品。也许需要重新思考一下如何合理地购买衣服。

首先应该知道我们对于衣服有哪些具体的需求，而需求取决于场景，也就是基于个人的活动来选择衣服。宽泛地说有工作、休闲、运动、户外、通勤、商旅、仪式、聚会等等。在每个场景下，又有一些细分的情景。

对于所有场景，季节与气象都是需要仔细考虑的。此外每一类场景都有其特殊的需求。对于通勤/户外场景来说，移动方式与具体的天气会影响衣物的选择：比如夏天简单穿个衬衫，大风天需要防风外套。如果是下雨天，那么不可能随便穿一层容易被水损坏的衣物在最外层，通常会穿一层轻微防水或至少是防泼水的面料。对于聚会/仪式的场景，就有正式程度的差别。运动模式下，穿衣还取决于类型、强度与具体环境，比如环法自行车运动和高海拔登山运动，其所需的装备天差地别。商旅则要在耐用、便携与正式度之间做权衡，既需要在旅途中保证衣物强度足够不容易损伤，也要保持尽量得体。

另有一些个人喜好相关的，如个人对面料舒适程度的体感，对衣物风格的偏好，以及对护理方式的选择也会影响衣物的选择。

确定好所有可能的场景后，就可以针对这种场景列举对于衣物的具体需求了。

面料材质方面的特性主要有：防水、防风、防油、吸湿、透气、速干、轻薄、抗皱、垂顺、挺拔、光滑、粗糙、弹力、光泽、厚度、颜色、织法、纹路样式等。

版型方面的特性主要有：正肩落肩插肩、肩宽、领胸腰下摆围、腰臀大腿裤脚围、前后浪（这些体现了合体程度）、衣长、裤长、袖长（这些反映了便携程度与风格）等。

设计上的小特点就太多了，翻领立领无领、口袋形式（唇袋、明贴袋、盖袋等）、内袋、腰带、风纪扣、喉襻、袖带、下摆收紧带、裤腰类别（那不勒斯、廓尔喀、好莱坞、常规腰）、翻折裤脚、衬衫袖（法式袖/常规袖）、瀑布褶（袖与背部）、风琴褶、裤褶数量……

我们来试着分析某些场景下对于衣物的具体需求。

例1：冬天，通勤，较大风，无雨雪。移动方式涵盖乘车、自行车、步行。

首先需要确定的一定是功能性方面的需求。大风的冬天，防风保暖是第一位，着衣时就需要保暖层以及防风层。由于无雨雪，因而不需要达到防水等级。由于移动方式包括了自行车，所以需要便于活动。同时，在轻微活动的情况下，排汗也需要纳入考虑。

假设上身遵守某种三层穿衣法，那么需要考虑的需求如下：

吸湿排汗性较好的最内层
容纳热空气的保温层
防风性能强的最外层

为了便于活动，则衣长在站立时不易超过手指；为了维持防风不漏风，衣长也不宜过短，下摆应在裆部以下。

依次考虑后，最内层可以考虑速干科技面料内衣或羊毛衫；保温层可以是抓绒，摇粒绒夹克，或是填充 p 棉的棉服，或是重磅的羊毛呢夹克；防风层可以是防风面料的M65野战夹克，或者是软硬壳冲锋衣。当然由于不需要防水，也可以合并外两层为一件羽绒服，不过不能是长款。

接下来在这些选择之中，就可以再根据个人风格偏好选择合适颜色、材质、样式的单品。总之丰俭由人。就好比“防风面料的M65野战夹克”，当然可以选择带有聚氨酯防水压层的面料会比较便宜；也可以选择LP的Storm System/Rain System等。

例2：夏天，仪式，较正式，室内（室温20℃）

这里并不单单要考虑单独的场景，而是有场景的转换。不管是什么活动，人都要首先移动到活动场地，肯定会去到室外，就要考虑如何在两层衣服的情况下也尽量凉快。需求如下

得体的内层，单穿也没问题
透气凉爽的外层，不会把汗闷在里面。同时面料垂顺无过多褶皱
轻薄透气干爽亲肤的长裤

总的来说，夏天的贴身层不适宜穿速干面料以外的化纤面料。其拒水性会导致肤感不好。而速干科技面料并不会拿来做正装。内层几乎只能选择衬衫的情况下，可以选择棉质的泡泡纱面料，或者是亚麻/棉麻混纺材质。外层可以选择毛麻混纺/泡泡纱/强捻的西服外套。较正式的情况下，几乎只能选择藏蓝色，当然这也取决于参与者的身份。西裤可选用强捻羊毛、毛麻混纺。

这类场合的可选项的确不多。甚至不适合选择黑色西装，因为正式程度太高了。

例3：温暖的春天，休闲，室外，随时可能下小到中雨

春天基本上是所有人穿五花八门漂亮衣服的时候了，选择是相对自由的。以上场景其实可以分成两种情况

1、试图通过衣物临时挡雨，等待雨势减弱再移动

2、我带伞了

第二种情况我们就随便掏一个内搭加一个外套就可以了。对于外套的偏好可能促使人选择风衣、野战夹克、猎装夹克、西装夹克、飞行夹克、哈灵顿夹克等不同的选项（长度）。第一种情况呢还是需要防水面料的衣物，而且要么衣服自带帽子，要么有单独的宽檐帽且上衣的衣领可以关紧，以防雨水灌入。

新年序曲

2026-01-12T16:00:00.000Z

自摔断腿纪年法的诞生以来真是发生了很多事，我同时因为时光被填满而感到漫长，又因为事情接踵而至感到仓促。

年初在家养伤的时间都在自由充电。被禁锢在床上的三个月里可消遣的项目也只有读书看电影，从各种媒介接受输入。要问收获恐怕已经答不上什么，潜移默化的影响也许有吧。三月慢慢出来走动，在学校过了几个月的逍遥独居日子。也没做什么，和社里快要毕业滚蛋的同学混日子，也许只有我在纯粹地混日子。本来没打算实习，但先是在第三领域被企业的人抓着投简历，转头老板又来电话让我改投另一个部门，这样实习经历的问题也解决了。搬到上海住了几个月，秋招拖拖拉拉到十月才开始忙活，借公司的会议室面试别的公司，在痛苦的等待中接了好像还不错的合同。十一月回到南京，在二〇二五年的末尾进入了彻底的躺平模式，仿佛毕业论文已与我无关。

年内去了镇江，丹阳，徐州，西安；在上海和南京之间多次往返。拖着还不算很灵活的腿脚到处乱跑，脚力也许就能多回复一点。其中只有西安把我折腾得够呛：从华清池到兵谏亭好一段山路，原来蒋光头当年体力也还不错。

八月底和在学校认识的女人谈恋爱，十二月底又分手了。这已经是上了大学之后最久的一段了。没什么利益上的考虑反而让我觉得没什么好妥协的，很干脆地放弃了。我想也许长长久久的恋爱不属于我认同的爱情的范式。所以兴许需要重新思考婚姻这件事。

在那之后又得知两位国际友人分手的消息，当即比我自己分手还要感到遗憾。孩子们，桌游组可能彻底歇逼了。随着毕业的分手的诸如此类的不可抗力因素奖池还在累计，往日种种最终还是再无话说速速动手。届时也许会变成：“我做出这一决定，是基于原则性的考虑的……”。

夫人之相与，俯仰一世，或取诸怀抱，悟言一室之内；或因寄所托，放浪形骸之外。虽趣舍万殊，静躁不同，当其欣于所遇，暂得于己，快然自足，不知老之将至。及其所之既倦，情随事迁，感慨系之矣。

我始终认为这段话是在说人的相处，本就是一群人个性各不相同，偶然找到一个暂时的共通之处，相处而快乐一阵。后来不可避免地有所厌倦，人之间的感情又随着现实的发展产生了变化，只能对当时的欢乐以及后来的变迁感慨一下。这样理解太符合我的认知，甚至是符合我的愿望以至于我现在不知道王羲之原本想表达的是什么了。也许在绝大多数情况下，人与人的关系就像一阵风。

只有一件事是确定的。那就是我也说不清楚这些是为什么，不知道我在期待什么，不知道自己在想什么。答案只能凝结在寻找的过程当中。

祝看完的老板永远健康永远快乐永远不死永远爽。

杂谈

2026-01-12T16:00:00.000Z

人毕竟不是铁打的，意志力只是有限资源。我常常刻意强调san值很重要。san值低了之后做出的事情容易让人掉HP，如果做事情不考虑情绪成本，最终一定会自己斩杀自己。

<未完>

一个月后接着想写已经不知道当时想说什么了。真遗憾啊。

如何洗衬衫

2025-12-17T16:00:00.000Z

这里讨论的是一般的纯棉衬衫应该怎么机洗。更耐造的面料是通用的，但是娇贵的还是请专业人员。

准备一堆穿过的衬衫、衣领净、洗衣液、衣物消毒液（选用）。

首先是预处理。衬衫在穿着的过程中，领口、袖口和腋下是比较容易脏的。对于我来说，主要是领口。我觉得这个可能会看得比较直观。穿过的白色衬衫领口会泛黄；对于彩色的衬衫，一般领口处的颜色会因为皮肤油脂渗入，变得深一点。这种我们提前喷好衣领净再去洗。

处理好特殊部位之后，开始扣扣子。一般的衬衫是7颗纽扣，可以都扣上。如果人比较懒也可以隔一个扣一个。然后我们把衬衫的大身内外翻过来，袖子留在大身的里面，领子你就立起来。这样在洗的时候面料可以把纽扣尽量包裹住，不容易在洗衣机里转的时候把扣子打碎了（树脂扣几分一个，贝壳扣一块钱）。另外袖子在里面呢也防止在洗衣机里拉拉扯扯。扣扣子这一会儿，基本刚才衣领净也就在起效了。

接下来就正常机洗流程。

出锅之后把衬衫完全翻到正面来，其实基本上在洗衣机里面就已经翻得差不多了。挂一个肩宽适合的衣架，然后需要手动拉扯整平一下。对于几处要特殊注意：

门襟，可能比较容易起波浪起皱
大身侧缝
袖子与大身的接缝
袖子的缝合处
袖子开袖衩处
袖口衬与袖子的缝合处
后肩片与后片的接缝

*总之，就是各种两片布料缝合的地方以及一些边缘，都可以扽一扽去整平。

一般，我们就悬挂晾干。

如果要烘干，建议考虑一下几点：

制作精美的衬衫尽量不要烘干，高温损伤会比较严重（使用的辅料的抗造程度、性质不同，可能导致产生的效果很哈人）
亚麻面料不要烘干，起皱严重
含粘胶纤维不要烘干。又缩又起泡
袖口、领底是粘合衬不要烘干。会起泡。当然水洗也会起泡

对于我而言，主要是领子清洁那一步和最后整理的一步很重要。

和爱人

2025-10-03T16:00:00.000Z

近期和爱人很好。这是实习以来鼓舞我的事情之一。

我颇有私心地将我的感情作为磨练我爱人、理解人的能力的一种考验。其实我并不知道我到底做得怎样好，或者怎样坏。也许这样的程度就是“将将好”，也许总归还是不够。我觉得我的热情其实是不足的，但索性爱人没有给我任何大考。说是没有，其实换任何另外的人来也许都不能做得比我好，毕竟她喝完酒之后就会陷入一种深深的…摆出激烈的回撤的姿态。我总是劝慰她下次别喝那么多，而她总是下次一定。在一起的时光甜蜜，而分开的时候，能算是稳定吗？也许我的热情不足这块给了她一些不安，但总之——只要见面就好。这点也不一定会奏效。

我们有无数的时间不能在一起，这一点可预见地并不会随着我们脱离了学生的身份之后就好转，尤其在我四处物色发展机会的时候，这里要去北京了，那里要去新疆了。而爱人又分离焦虑爆炸，我不敢赌定我是不是每次都能够处理好。也许只有一次次地在城市之间往返，稍微平息一下那样的冲动。

感情中的我过于稳定了，既像爱人最开始喜欢上我的某一点，也就是一种 NPC 感。我又何尝不是以第三人称视角来看这份感情呢？不过我们彼此之间都没有强迫，于她而言可能是怕添麻烦，而于我而言…可能更多是无所求。这种热情消失的感觉并非是逐渐的，而是从一开始就如此，甚至在别的方面也有体现。

我似乎并不能一下就说出很多大话来了，同任何人交谈的时候，我开始首先审视自己的态度，然后再审视别人的态度。最后尽量想端水，或者说平衡。我说不清楚这里到底经历了什么。

我有一个理想中的世界，以及理想中的对话者。祂应当秉持着什么样的态度与我对话。我承认人都有主观的偏好，甚至过于承认了。我拒绝人把主观的偏好推而广之，不加以提示地告诉所有人。也就是拒绝一些“小马过河”式的建议。我希望所有的话都是“我自己的经验是xxx，我觉得xxx。你可以参考一下。”如果有人突然就祂自己的经验而发表论断，我一时竟会感到愤怒，然后想祂也有祂自己的原因，最后多少表达抗议。

我自己也在逐渐避免这样，也许。为别人提供视角，越来越大于提供观点。因此我也总是把一两个寓言故事挂在口头，作为一种随时的提醒。但我的观点又不能说不强烈，事实上我为我认识到、想明白一些事情感到非常骄傲，或者说是自信。但为了与理想中的对话者这种描述自洽，又不得不收敛一点——兴许在其他人的眼里我可能还是比较 mean。不过我已经努力了。

与爱人也是这样。我觉得路要自己走，我觉得我不是任何救世主。所以我只是陪伴，以及从旁观看。事实上说也不可能说通，她的焦虑与痛苦，我知道是由她的本性决定，以及可能是因为我而引发的。但如果不爆发出来的话，我也就只能用三言两语去宽慰一下，然后陪伴等待。这是我作为一个对等点能做的所有事。对这个世界的态度，并不是能够学来的；终归有些事，并不是我能解决的…

FreeBSD TCP 实现中发现的两个 BUG

2025-09-24T16:00:00.000Z

我宣布现在没人比我更懂 TCP。

见邮件列表 Two different places between TCP socket behavior and RFC documents

虽然没有肉眼可见的 vulunerability / exposure 但多少还是被承认为 BUG 了…对方锐意修复中。

问题1. 关闭时有待处理数据，但未能发送 RST

根据 RFC 2525 第 2.17 节，当 close() 一个套接字时，如果其接收缓冲区中仍有待读取的数据，应该发送 RST（复位）。

根据 RFC 1122：主机可以实现一种“半双工”TCP 关闭序列，…不能继续读取数据…如果接收缓冲区中仍有待处理数据时进行 CLOSE 调用，或者在调用 CLOSE 后接收到新数据，TCP 应该发送一个 RST 以表明数据已丢失。

然而，FreeBSD 的 TCP 套接字并非如此。以下是 TCPDUMP 的输出，显示在套接字有待处理数据时调用 close() 发出的是 FIN（结束）而非 RST：

A > B: Flags [S], seq 2636678338, win 65535, length 0
B > A: Flags [S.], seq 1969223298, ack 2636678339, win 65535, length 0
A > B: Flags [.], ack 1, win 1277, length 0
A > B: Flags [P.], seq 1:6, ack 1, win 1277, length 5
B > A: Flags [.], ack 6, win 1277, length 0
B > A: Flags [F.], seq 1, ack 6, win 1277, length 0
A > B: Flags [.], ack 2, win 1277, length 0

无论是 close()、shutdown(SHUT_RDWR)、shutdown(SHUT_RD)，还是 SO_LINGER 设置为开启或关闭，都得到相同的结果。而在 Linux 上，同样的操作会得到以下结果：

A > B: Flags [S], seq 2879877684, win 65495, length 0
B > A: Flags [S.], seq 1538598692, ack 2879877685, win 65483, length 0
A > B: Flags [.], ack 1, win 512, length 0
A > B: Flags [P.], seq 1:6, ack 1, win 512, length 5
B > A: Flags [.], ack 6, win 512, length 0
B > A: Flags [R.], seq 1, ack 6, win 512, length 0

当然，虽然没有发送 RST，但是这里不会像预期的那样导致连接一直保持。因为它的 FIN segment 实际上重新打开了窗口。

A > B: Flags [.], ack 1, win 510, length 0
B > A: Flags [.], ack 66137, win 0, length 0
A > B: Flags [.], ack 1, win 510, length 0
B > A: Flags [.], ack 66137, win 0, length 0
A > B: Flags [.], ack 1, win 510, length 0
B > A: Flags [.], ack 66137, win 0, length 0
B > A: Flags [F.], seq 1, ack 66137, win 1027, length 0

我们通过发送大量数据，使得对面最终通告了 0 窗口。但在对面进行close() 后，它又打开了窗口。此时发送端就又可以发送数据，包括发送 FIN 了。

如果发送数据，而对面已经做了接受方向的关闭，则会得到一个 RST；如果发送 FIN，也就能完成四次挥手。看起来都能够使连接关闭。但这里的问题在于，打开接收窗口与关闭接受方向显然是矛盾的。尤其是，打开窗口邀请对面发送数据，而这数据是必定会被自己所拒绝的，这造成了一些不必要的网络流量以及处理资源的浪费。

另一方面，FIN 标志着优雅地关闭了连接。但这里显然并不优雅。我们需要用清晰的报文来标志异常。

数据发送/强制重置比起主动重置除了少量资源消耗以外，使得关闭这件事整体变得复杂了….

问题2. 在 SYN-RECEIVED 状态下对旧序列 segment 回复 RST 而非确认

根据 RFC 793 第 69 页：如果一个传入的 segment 不可接受，应该回复一个确认（这里“应该”没有大写）。

这应该适用于包括 SYN-RECEIVED 在内的所有状态，但 FreeBSD 的 TCP 套接字并非如此。我用手动构造的 TCP 分段发现了这个问题：

A > B: Flags [S], seq 1, win 8192, length 0
B > A: Flags [S.], seq 4054810353, ack 2, win 65535, length 0
A > B: Flags [.], ack 1, win 8192, length 0
B > A: Flags [R], seq 4054810354, win 0, length 0

预期的行为是发送一个空的确认：

A > B: Flags [S], seq 1, win 8192, length 0
B > A: Flags [S.], seq 3620804602, ack 2, win 65495, length 0
A > B: Flags [.], ack 1, win 8192, length 0
B > A: Flags [.], ack 1, win 65495, length 0

这与 Linux 的行为是一致的。

上文发送后，维护者似乎不是很明白，于是我作了如下解释：

考虑以下 TCP 握手序列：

套接字 A 向处于 TCP_LISTEN 状态的套接字 B 发送一个 SYN（同步）分段。
套接字 B 转换为 TCP_SYN_RECV 状态，并以进行响应。
套接字 A 没有发送预期的来完成三次握手，而是错误地发送了。

根据 RFC 文档，对这种窗口外 ACK 的恰当响应应是一个空的 ACK 分段。之后，套接字 B 应等待一个有效的 ACK，或者在必要时重新传输 SYN-ACK。

然而，在 FreeBSD 当前的实现中，它发送了一个 RST（复位）分段，格式为，这会 prematurely 终止连接。

这种行为似乎偏离了 RFC 的指导，并可能导致不必要的连接重置。

对于窗口不同程度的偏离都观察到了这一现象

1. expect seq=2, actual seq=0x80000001
2. expect seq=2, actual seq=0x80000002
3. expect seq=2, actual seq=0x80000003
4. expect seq=2, actual seq=0x90000000
5. expect seq=2000001 (0x1e8481), actual seq=1
6. expect seq=1, actual seq=2000001 (0x1e8481)
All of them, under FreeBSD, give a RST reply. Here is the tcpdump of the first
case.

A > B: Flags [S], seq 1, win 8192, length 0
    0x0000:  4500 0028 0000 4000 4006 0000 7f00 0001
    0x0010:  7f00 0001 22b9 22b8 0000 0001 0000 0000
    0x0020:  5002 2000 4c6e 0000
B > A: Flags [S.], seq 1643153760, ack 2, win 65535, options [mss
16344], length 0
    0x0000:  4500 002c 0000 4000 4006 0000 7f00 0001
    0x0010:  7f00 0001 22b8 22b9 61f0 8960 0000 0002
    0x0020:  6012 ffff fe20 0000 0204 3fd8
A > B: Flags [.], seq 2147483648, ack 1, win 8192, length 0
    0x0000:  4500 0028 0000 4000 4006 0000 7f00 0001
    0x0010:  7f00 0001 22b9 22b8 8000 0001 61f0 8961
    0x0020:  5010 2000 e10d 0000
B > A: Flags [R], seq 1643153761, win 0, length 0
    0x0000:  4500 0028 0000 4000 4006 0000 7f00 0001
    0x0010:  7f00 0001 22b8 22b9 61f0 8961 0000 0000
    0x0020:  5004 0000 fe1c 0000

C23 标准手册拾遗（四）

2025-08-27T16:00:00.000Z

今天想赶快把 ext4 的教程翻完。setjmp 拖一下。

C23 标准手册拾遗（三）

2025-08-26T16:00:00.000Z

注意到 enum 可以有 underlying type

enum no_underlying {
  a0
};
int main(void) {
  int a = _Generic(a0, 
        int: 2,
        unsigned char: 1,
        default: 0
  );
  int b = _Generic((enum no_underlying)a0,
        int: 2,
        unsigned char: 1,
        default: 0
  );
  return a + b;
}

此时 a 一定是 2，没有 underlying type 的枚举值默认是 int。而 b 是实现定义的：enum 的 underlying type 只要能容纳其枚举值即可。

enum underlying : unsigned char {
  a0
};
int main(void) {
  int a = _Generic(a0, 
        int: 2,
        unsigned char: 1,
        default: 0
  );
  int b = _Generic((enum no_underlying)a0,
        int: 2,
        unsigned char: 1,
        default: 0
  );
  return a + b;
}

保证一定是 1。

注意到 restrict qualifier

像是一种优化提示，告诉编译器我这些指针指向的内容在函数运行期间不会被其他的任何途径访问到。

场景：数组在函数当中不会被访问

Restriction：只能从作用域内向外访问。

例外是作为返回值：

详见 6.7.3.1。大半夜读读剩下来几个例子我有点 注意力涣散

注意力涣散 函数声明

我以前还真的没有想过，对数组名取地址到底有什么效果。（其实就是普通的取地址）

It’s pointer to int[3]，i.e. int (*)[3]

scanf 似乎接受 char s[] 字符串的地址 &s，以及字符串的指针 s。它们只是值相同而类型不同。前者会给出类型不匹配的 warning。

注意到 这个可以用来作 C 语言课程的教学内容

还是在想，是不是 C 语言课程应该首先科普 “指针” 的概念？然后再教别的。在这之前，首先要介绍 “内存” 是怎么工作的。。。

第一节课，应该是数据：类型和数组——的机器和 C 语言表示，以及少量 io。所有东西都简化到内存中去，不考虑寄存器。

initializer 也会有踩踏。

注意到 standard attributes

这看起来很能函数式。还有 [[unsequenced]]。明天来写个详细的。

是不是以后算 fib 都不用记忆化存储的？

–答案是不能。看似这个 attr 只能优化掉编译期可以推导出的参数，而不是动态地 cache 相同参数的结果。testcase：

/* foo.c */
int foo(int n) {
    return n + 42;
}

/* bar.c */
int foo(int n)[[reproducible]];

int main() {
    return foo(0) + foo(0);
}

如果没有 [[reproducible]] 声明，在编译单元 bar.c 中不知道 foo 是纯函数，为了保留副作用，会进行两次调用。声明之后，有两次 foo(0) 纯函数调用，会被合并为一次。

0124 = 84 = 42 + 42。

如果 foo 的调用参数里有运行期变量的话，就一次也无法优化。具体的例子是：

1 2	for (int i = 0; i < 10; i++) foo(i); for (int i = 1; i < 11; i++) foo(i);

这样会调用 20 次而不是推导出两个循环里有相同参数的调用。

要观察到这个现象不能放在一个文件里。否则常量折叠会直接干碎所有调用。另外注意添加 -O2/-O3 优化，毕竟 attr 是为了优化而生的。

检查编译器是否支持：

1	static_assert(__has_c_attribute(reproducible) == 202311L); // 写在代码任意位置

注意到 C23 支持了 #embed，编译期嵌入二进制文件。

哈哈，数学公式爆了

使用例：

这个编译期嵌入随机数的例子还挺有意思的：

limit 参数将影响 if_empty 的判断。

注意力涣散 感觉很复杂的 __VA_OPT__ 但是一时不知道该怎么用

看了第二个例子感觉有点懂了。如果 ... 存在的话，就把 __VA_OPT__ 的参数放进去。没有的话就不放。

这不是构造函数吗（？）

#define H5A(...) __VA_OPT__(0)/**/__VA_OPT__(1)
#define H5B(X) a ## X ## b
#define H5C(X) H5B(X)
H5C(H5A(1)) // replaced by a0 1b

最后一个例子换一下，中间就会多一个空格。说明每一个 __VA_OPT__ 都会产生一个单独的 pp-tokens 而不是连成一个。

注意力集中 ## == # ## # != ##

注意到 assert() 将会被 NDEBUG 宏 disable

有这样的一个 pragma：

可以让用户保证类型安全的情况下用这些公式进行计算。

复变反三角函数是一个多值函数。因而要 cut 它的一个解析分支出来

cacos 剪掉了实轴上 [-1, +1] 以外所有的定义域，只保留主值。（表达可能不精准，我没咋学过复变）

其他三角函数也类似。

注意到 中的函数除非文档显式说明了，否则保证不会抛出 SIGFPE

注意到 这些函数可以对齐浮点数的阶数

并有判断函数

前面还有函数能够 “返回下一个可表示的数”，大概是用于数值计算一类的应用或者是 debug 浮点实现。

安全的浮点数比较：

明天来开 setjmp.h。

C 赋值运算符条件探讨一则

2025-08-25T16:00:00.000Z

前置知识：至少需要知道 C 语言中的 (const) qualifier 的修饰对象

读 C23 手册读到了赋值运算符下面的一个例子：

const char **cpp;
char *p;
const char c = ’A’;
cpp = &p; // constraint violation
*cpp = &c; // valid
*p = 0; // valid

假如 line 4 的赋值可以执行，那么最终 line 6 会改变 const char c 的值。因此不被允许。

但是仔细想想其实这件事情有点反直觉。因为 line 4 中，cpp 是 const char **，&c 是 char **。这里 cpp 显然是变量而不是常量，因为 const 修饰的是 char。而且因为右操作数是 char **，因而这个赋值似乎并没有 discard 任何的 qualifier（实际上有）。尽管笔者理解不能使得上面的例子成功执行，这样一种目的上的设计“原因”；但并不明白，是哪几条设计或机制在事实上让这样的程序编译得不到通过。毕竟看起来是这么合理。有多合理呢？看看下面的例子：

// 1. assign char * to const char *
const char *c;
char *b;
c = b;   // OK

// 2. assign char ** to const char **
const char **c;
char **b;
c = b;  // FAIL

第一个例子看起来无比自然、甚至非常常见，以至于我就算在群友的提示下还是花了很久才弄明白第二个为什么不能通过。

这是为什么呢？我今天下了班再来写…最后那天晚上一回来就一觉睡到早上了。

首先我们来介绍一个概念：Compatible Type（兼容类型）

C 语言标准手册 6.2.7 中说：两种类型是 compatible types 如果它们相同。这一小节里介绍了结构、联合体和枚举类型的 compatible 规则。总结下来就是一一对应。可以认为，它们的每个成员必须保持类型 compatible、qualifier 一致、attribute 一致且成员名一致。另外，对于数组类型，有一套独特的规则：

总之可以理解为全等。

在此基础上，在 6.7.6.1 里介绍了指针类型的 compatible 规则：

For two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types.

指针本身的 qualifier 必须全等，并且它们指向的类型需要 compatible。

在 6.7.3 里介绍了一般类型的 compatible 规则：

For two qualified types to be compatible, both shall have the identically qualified version of a compatible type; the order of type qualifiers within a list of specifiers or qualifiers does not affect the specified type.

两个类型必须表达（不是拥有的 “have”）相等地 qualified 版本的 compatible 类型。比如 const volatile int 和 volatile const int。就是说，顺序可以不一样，但是个数和类型必须一样。

原文里给了一个极端的例子：

这里可以看出，const 不一定是常量，而是不应被程序修改的量。

接下来回到今天的例子。

char 和 const char 并不 compatible。因为它们是 compatible type char 的 differently-qualified version。

因而 char * 和 const char * 并不 compatible。因为它们分别指向 incompatible type char 和 const char。

因而 char ** 和 const char ** 并不 compatible。因为它们分别指向 incompatible type char * 和 const char *。

……

根据我们的观察，我们不可以把 char 赋值给 const char:

const char a;
char b;
a = b;  // FAIL

const char c = b;  // OK

因为 Assignment 表达式的通用约束是：

左操作数必须是可修改的左值。

注意到 line 5 的写法是 Initialization（6.7.10）。它由 initdeclarator 构成：

initializer 进一步包含了 Assignment-expression（6.5.16）。但是这个 Assignment 表达式并不一定是带等号的式子，它经过语法单元的分解，最终下降到了 primary-expression。

assignment-expression:
  conditional-expression:
    logical-OR-expression:
      logical-AND-expression:
        inclusive-OR-expression:
          exclusive-OR-expression:
            AND-expression:
              equality-expression:
                relational-expression:
                  shift-expression:
                    additive-expression:
                      multiplicative-expression:
                        cast-expression:
                          unary-expression:
                            postfix-expression:
                              primary-expression:
                                identifier
                                constant
                                string-literal
                                ( expression )
                                generic-selection

所以，line 5 中的 assignment-expression 其实是 b。

1
2
3

const char c       // declarator
    =              // =
  b;               // initializer -> assignment-expression -> -> .... -> identifier

在初始化当中，

规则就和 simple assignment 类似，其中 initializer 取标量类型的 unqualified 版本作为其声明类型。

手册没说聚合类型怎么办，虽然实际上都是推广了的。也有可能是我找错位置了。

我们可以把 char * 赋值给 const char *：

1
2
3

const char *a;
char *b;
a = b;  // OK

其成立的理由在于，它两侧的类型符合 Assignment 表达式 的要求。

此处适应的条件是第三个：

左操作数有 atomic, qualified or not 的指针类型（也就是任意指针），而两个操作数都指向了 或者是 qualified，或者是 unqualified 版本的 compatible types，其中：左操作数指向的类型拥有右操作数指向的类型拥有的全部 qualifier。

我们依次来看：

左操作数是指针类型。Good
左操作数指向了 const qualified 的 char 类型；右操作数指向了 unqualified 的 char 类型。char-char 之间 compatible。且 {const} 包含空集。Good

因而这个赋值表达式的约束成立。

再来看主角：

1
2
3

const char **a;
char **b;
a = b;  // FAIL

左操作数是指针类型。Good
左操作数指向了 unqualified 的 const char * 类型；右操作数指向了 unqualified 的 char * 类型。上文提到，const char * 和 char * 并不 compatible。Bad

即为这段代码编译不过的形式原因。

char * 的 const-qualified 类型是 char *const。所以可以：

1
2
3

char *const *a;
char **b;
a = b;  // OK

对四因说的一点解释

2025-08-24T16:00:00.000Z

亚里士多德提出了四因说，我在这里给出一解。

质料因，就是全部矛盾的全部方面，主要是主要矛盾的两个方面。矛盾发展当中有什么样的势力，这些势力强弱如何，在质料上决定了矛盾的发展方向。

形式因，就是主要矛盾本身。什么样的矛盾存在，就会有什么样的发展。

动力因，就是推动矛盾发展收敛的那个力量。矛盾本来就有怎样的趋势，但经过这样的推手，矛盾看起来突然有了一个显著的方向。可以说质料因充当了这个矛盾的热力学因素/必然性，动力因充当了矛盾发展的动力学因素/偶然性。

目的因，就是这一矛盾最终要扬弃自身的趋势。

跳跃到精神分析的“断句”实践——我喜欢管这个叫实践而不是技巧、技术。在听到提问原因的时候，其实提问者总是在期待这四种当中的某种，通常是动力因和目的因。这时候其实可以回答前两类原因。

Q：你为什么要问这个？

A：因为我最近听说xxx感到有点好奇（动力因）/ 因为我好奇这件事（目的因）/ 因为我是一个好奇的人而你看起来知道（质料因）/ 因为我俩在这总得聊点啥（形式因）

Linux ext4 文件系统的最简完整教学（译）持续更新中

2025-08-23T16:00:00.000Z

根据原文要求，本文以 Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License 进行许可。

原文作者：Mete Balci

原文：A Minimum Complete Tutorial of Linux ext4 File System

2017 年 8 月 25 日

翻译：Tilnel @ 2025 年 8 月

为了避免歧义，译文的叙述部分使用 1Ki(B) = 1024(B) ，依此类推，而不是原文的 K(B)。

#引言

我尽量使用例子简洁而全面地描述 Linux ext4 文件系统。

声明：我不是 ext4 方面的专家。尽管我写这篇文章的目标是使其尽量全面足以理解 ext4 如何工作，但也忽略了很多特性。所以这并不是完整的描述。

我管这个叫做“最小完整教程”是因为我会忽略一些可选的部分，以及一些额外的特性，以此保持简洁。在此基础上全面地描述 ext4 的所有功能。ext4 并不简单，所以完全读完可能需要几个小时。

我没有按照先后顺序去执行教程中的例子，所以由于文件系统是动态的如果你自己去尝试执行的话，可能得到不一样的结果。不过这并不影响我们理解原理。

#相关资料

我参考了 Ext4 Disk Layout documentation，ext4 文件系统在 Linux Kernel 中的源码，e2fsprogs（包括 debugfs 和 dumpe2fs），以及 coreutils 的源码（包括 ls）。

#历史

从 2010 年开始，ext4 就是 Linux 的默认文件系统，它是 ext2、ext3 的继任者。“ext” 的意思是 “extended”，第一个版本的文件系统就叫这个。在 1992 年左右它被采用了很短一段时间后就被 ext2 取代了。2000 年时，支持文件系统日志的 ext3 也诞生了。

#教程

#创建 ext4 文件系统

如果你在用 Linux，可能你已经把 ext4 作为你的主文件系统了。不过，为了保护你的文件，我们还是重新创建一块来供我们实验吧。这里我在 /dev/sda 的一个 U 盘上创建了一个 ext4 文件系统。

首先我创建了一个包含了一个 Linux 分区的 GUID 分区表（GPT）。如果你对 GPT 和 Logical Block Addressing（逻辑块寻址，LBA）不熟，推荐你先阅读我的这篇文章：A Quick Tour of GUID Partition Table (GPT)。

小心！使用 fdisk 和 mkfs 的时候要非常非常注意。确保你写入的设备上没有重要数据。

这是分区表：

$ sudo fdisk /dev/sda

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Command (m for help): p
Disk /dev/sda: 14.9 GiB, 16008609792 bytes, 31266816 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 68B7F722-7E83-47F7-BCCC-2C7591B95E0C

Device     Start      End  Sectors  Size Type
/dev/sda1   2048 31266782 31264735 14.9G Linux filesystem

逻辑块 ^[1]大小是 512 字节。分区从第 2048 个逻辑块开始，到第 31266782 个逻辑块结束。

我们就在这个分区上创建文件系统。

$ sudo mkfs -t ext4 /dev/sda1

mke2fs 1.42.13 (17-May-2015)

Creating filesystem with 3908091 4k blocks and 977280 inodes
Filesystem UUID: 5ae73877-4510-419e-b15a-44ac2a2df7c6
Superblock backups stored on blocks: 
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

mkfs，制作文件系统（make file system），通过 -t 指定文件系统，这里是 ext4。mkfs 其实是一个 wrapper，它会根据文件系统调用对应的 mkfs.。所以这里是 mkfs.ext4 在执行。

这里我们可以看到：

一个包含了 3908091 个块的文件系统被创建。
块大小是 4096 字节，这是自动选择的。我们也可以使用别的块大小。块大小和逻辑块大小（LBA所使用的）并不一样。这里说的约 4 百万个 “block” 指的是文件系统块而不是逻辑块。
有 977280 个 “inodes”。我们之后将会了解这个。
文件系统 UUID 就是 GPT 中的分区 UUID。
有 group tables，inode tables 和 journal（日志）。
最后有一个统计数据。我在 mkfs 的源码中找了找，发现它实际上也就写了一些文件系统信息。所以文章也不会特别提到。

文章将会解释所有这些和相关概念。

#Superblock

我们从 Superblock 开始，因为它是包含了文件系统基本信息的一片位置固定的区域。我们可以使用 dumpe2fs 的 -h 仅打印 Superblock 选项来导出其内容。

$ sudo dumpe2fs -h /dev/sda1

Filesystem volume name:   
Last mounted on:          
Filesystem UUID:          8eefa5bb-858c-4bd0-b80d-1aebc23de317
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              977280
Block count:              3908091
Reserved block count:     195404
Free blocks:              3804437
Free inodes:              977269
First block:              0
Block size:               4096
Fragment size:            4096
Reserved GDT blocks:      954
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8144
Inode blocks per group:   509
Flex block group size:    16
Filesystem created:       Wed Aug 23 11:20:00 2017
Last mount time:          n/a
Last write time:          Wed Aug 23 11:20:00 2017
Mount count:              0
Maximum mount count:      -1
Last checked:             Wed Aug 23 11:20:00 2017
Check interval:           0 ()
Lifetime writes:          132 MB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      648ce1ac-dd8d-40a6-ac6f-238b2e7d97d1
Journal backup:           inode blocks
Journal features:         (none)
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00000001
Journal start:            0

这边信息非常多，我会解释其中的大部分。

ext4 最基础的存储布局概念就是 Block（块）。ext4 以块为单位分配存储空间，就像是 LBA 一样。然而 ext4 Block 大小可能不一样。在 Superblock 中是 4096B = 4KiB。文件系统中的 Block 总数是 3908091 个。

第二个概念是 Block Group（块组），也就是固定数量的连续的块。在我们的文件系统中 Group 大小是 32768 = 32Ki。

我们有 3908091 个block。将其除以 32Ki:

1 2	3908091 / 32768 = 119, 因为它不是 32Ki 的整数倍, 所以还会有一个比 32Ki Block 小的 Group。

所以我们有 119 个 32K Blocks 的 Groups 和一个小的 Group。每个 Block 是 4KiB。由于每个逻辑块（扇区）是 512B，这意味着每个块有 8 个扇区。这就是 ext4 的基本存储安排，如下图所示。

每一个块组都包含：

Superblock，包含文件系统的信息。位于每组的第一个块。
（块）组描述符（表）【(Block) Group Descriptors (Table)】包含了数据块 Bitmap，inode Bitmap 和 inode Table 在块组中的位置。每个块组都有一个组描述符。根据组大小的不同，它有可能占据一块或多个块，并且总是跟在 Superblock 后面。
预留的组描述符表 块。这些是为了未来扩展文件系统的时候预留的。ext4 文件系统的大小可以调整，如果是扩展的话，就意味着有更多的块，更多的块组。更多的组描述符就需要空间。通常是紧跟在 GDT 后的 0 或更多个 block。rezise_inode（在 Superblock 的 Filesystem features 中）标志了预留存在与否。
数据块 Bitmap。标识了哪些数据块已经被使用了。它占据一个 block，位置不固定，在组描述符中指定。
inode Bitmap。标识了 inode Table 中的哪些项（entries）已经被使用了。它占据一到多个 blocks（经常是多个）并且位置不固定，由组描述符指定。
数据 Blocks。包含了实际的文件内容。占据一到多个 blocks。块组里除去上文所述，剩下的 block 都属于这部分。

在 Bitmap 中，每一个 bit 都标识了一个对应的 block/inode 的使用情况。由于 Bitmap 占据 1block = 4KiB = 32Kibits，故而块组中至多可以有 32Ki 个 blocks——事实上也是这样。并且，一个块组中最多可以有 32Ki 个 inodes，但上面的 Superblock 信息表示，我们只有 8144 个。

再回头看看 Superblock：

预留的 GDT 块有 954 个。用作未来文件系统的扩展。
每组的 inode block 有 509 个。这个数字与 inode size 以及每组的 inode 数量紧密相关。注意到 $256 B * 8144 / 4096 B = 509$。

目前为止我们还没有看到 ext4 文件系统布局的全貌。Superblock 的 Filesystem features 中还有两个至关重要的标志在影响着布局：sparse_super 和 flex_bg。

#Superblock Backups

Superblock 包含了文件系统的重要信息，丢失就等于文件系统完全损坏了。因而在设计的时候，这些 Superblock 在每个块组当中都有备份，或者说是冗余。然而这可能有点多了，比如在我们的例子中，其实是一个很小的文件系统，120 个块组难道真的要有 120 个备份吗？sparse_super 就标志了这样一件事，即只有少量块组存在 Superblock 的备份，特别是 0 号块组，以及编号为 3, 5, 7 的幂次的块。

对于我们的这个案例，从 0 到 119 号块组，以下的块组是包含了冗余的：

1	1 3 5 7 9 25 27 49 81

如果我们把每个数都乘上 32768 (=32Ki，每组的块数)，就得到了 mkfs 输出过的 Superblock 的备份块：

1	32768 98304 163840 229376 294912 819200 884736 1605632 2654208

sparse_super 也会影响组描述符。在默认情况下，组描述符在每个块组中都会有。但如果 sparse_super 被标记，组描述符就只会出现在上列含有 Superblock backup 的块组中。可以认为 Superblock 和组描述符总是在一起。

#块组和弹性块组（Flexible Block Groups）

另一个标志 flex_bg 代表 Flexible Block Groups，也就是弹性块组。这个特性是在 ext4 引入的。FlexBG 简单来说就是块组之上的一级管理，也就是“块组的组”，它把整个大组内所有块组的数据块 bitmap、inode bitmap 和 inode table 都聚合在第一个块组中。

继续观察之前的 Superblock，可以发现 FlexBG 大小是 16，所以每 16 个连续的块组就打包成一整个弹性组。每个弹性组的第一个块组就会包含下辖所有块组的数据块 bitmap，inode bitmap 和 inode table。

我们有：

1	120 / 16 = 7 ... 8， 7 个 16BG 和 1 个 8BG 的 FlexBG

注意：我们这里并没有 meta_bg 的 feature。这个 feature 对于块组的安排又是不一样的。

为了理解块组的内容，我认为大体可以将其简化为 3 类（请理解这只是我的描述方式，而不是官方的分类）：

Type 1a（在 Block Size = 1024B 情况下的 0 号块组，Block 0）：Block 0 被标记为使用但实际没有使用（因而前 1024B 都没有被使用）。Block 1 包含了 primary Superblock（主 Superblock，对应备-backup）。接下来是连续的组描述符块和预留的组描述符块。后面和 Type 3 相同。
Type 1b（在 Block Size > 1024B 情况下的 Block 0）：Block 0 的首部 1024B 作为 padding，没有被使用。从 1024B 的偏移量开始，是 primary Superblock。接下来与 1a 相同。
Type 2：包含了 Superblock 和组描述符备份的块组。Block 0 是 Superblock，接下来与 Type 1a 相同。
Type 3：不包含 Superblock 和组描述符备份的块组。可能包含数据块 Bitmap，inode Bitmap，inode Table，以及数据块。Bitmap 和 inode Table 的位置在组描述符中记录，所以顺序可能有变。

Block 0 首部的 1024B 可能被用作启动码，因而 ext4 不会使用它。

Superblock 中标识了 “First block value”。它只有在 Block Size = 1024 B 的时候才等于 1。其他时候都等于 0。

$ mkfs -t ext4 -b 1024 /dev/sda
$ sudo dumpe2fs -h /dev/sda1 | grep "First block"

First block:              1

在我们的例子中：

Type 1b 的 Block Group 有 1 个（0）
Type 2 的有 9 个（包含了 Superblock 冗余的块）
剩下全部 110 个都是 Type 3

当设置了弹性块组的时候，这些每类块组又分为两类，因为在弹性块组中只有第一个块组^[2]中才有 Bitmaps 和 inode Table。这里我会将它们命名为 Type 2-head / Type 2-rest，以此类推。Type 1 总是 head，因为它总是 Flex BG 中的 0 号。

同时，Type 2-head 块组是不可能的。因为备份块的序号总是 3, 5, 7 这些奇数。而 Flex BG 的 size 总是 2 的乘方，也就是偶数，意味着其头部块组的序号也总是偶数。所以 Type 2 作为备份快，不可能位于 Flex BG 的头部。

现在我们已经完全搞清楚我们的 ext4 文件系统的块组和块的排布了。事实上我们可以用 dumpe2fs 输出所有 Block Groups 的信息。

1	$ sudo dumpe2fs /dev/sda1 > dump

由于包含了所有块组（120个）的信息，文件会很长。下面逐一地去介绍。

第一个块组（Block Group 0）：

Group 0: (Blocks 0-32767) [ITABLE_ZEROED]
  Checksum 0x9a88, unused inodes 8131
  Primary superblock at 0, Group descriptors at 1-1
  Reserved GDT blocks at 2-955
  Block bitmap at 956 (+956), Inode bitmap at 972 (+972)
  Inode table at 988-1496 (+988)
  23630 free blocks, 8133 free inodes, 2 directories, 8133 unused inodes
  Free blocks: 9138-32767
  Free inodes: 12-8144

正如我们所知道的：

它包括了 0-32767 号块，因为每个块组有 32Ki Blocks
Block 0 包含了 Superblock
Block 1 包含了组描述符（且只有 Block 1 有）
Block 2-955 是预留的 GDT Blocks
Block 956 是数据块 Bitmap
Block 972 是 Inode Bitmap（我们后面再解释为什么不是 957）
Block 988-1496 是 inode table。$1496 - 988 + 1 = 509$，刚好和 Superblock 的信息对得上

也有不用 dumpe2fs 的办法，那就是手动解析磁盘的数据。

组描述符是从第二个 block 开始的，所以我们用 dd bs=4096 skip=1。前三个 32 位的数是数据块 Bitmap、inode Bitmap 和 inode Table 的位置。

1
2
3

$ sudo dd if=/dev/sda1 bs=4096 skip=1 count=1 status=none | hexdump -n 12 -s 0 -e '"%d %d %d\n"'

956 972 988

块组 0 在本文的分类学下是 Type 1b (head)。

第二个块组（Block Group 1）：

Group 1: (Blocks 32768-65535) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0x5017, unused inodes 8144
  Backup superblock at 32768, Group descriptors at 32769-32769
  Reserved GDT blocks at 32770-33723
  Block bitmap at 957 (bg #0 + 957), Inode bitmap at 973 (bg #0 + 973)
  Inode table at 1497-2005 (bg #0 + 1497)
  31809 free blocks, 8144 free inodes, 0 directories, 8144 unused inodes
  Free blocks: 33726-33791, 33793-65535
  Free inodes: 8145-16288

它有 Superblock backup。因为 $ 1 = 3 ^ 0$
因为有 Superblock backup，所以也有组描述符和预留的块
它在事实上没有数据块 Bitmap，inode Bitmap 和 inode Table。这些都引用了 Block Group 0 中的（e.g. Block Group 1 的数据块 Bitmap 在 bg #0 + 957）因为 Block Group 1 和 0 在同一个 Flex BG 中。inode Bitmap 和 inode Table 同理。这也就是为什么在 Block Group 0 中，数据块 Bitmap 和 Inode Bitmap 并不是连续的区域了。一个从 956 开始，一个从 972 开始，中间就是 16 Blocks，它们包含了所有块组的数据块 Bitmap 信息（从 0 到 15，$[956, 972)$）。以此类推，inode Bitmap 就是 $[972, 988)$，inode Tables 就是 $[988, 9132)$ (989 + 16 × 509 = 9132)

这里我有点困惑，也许你也有点感觉。在 Block Group 0 中，为什么 inode Table 在 9132 结束，但是可用空间从 9138 开始呢？其实 9132-9137 是已经在使用的数据块。所以这里并没有什么特别的怪事发生。如果重复实验的话，可能会得到不一样的结果。

所以在概念上我们其实不能说数据块在遵守这些元数据规定的结构，而是所有的块都是数据块，只不过有一些用来存储元数据了。存储元数据的块在数据块 Bitmap 中也是要被标记使用的。

Block Group 1 在本文的分类学里面是 Type 2-rest。它有 Superblock 备份，但不是弹性块组的第一个（因此没有 Bitmaps 和 inode Table）。

接下来是 Block Group 2：

Group 2: (Blocks 65536-98303) [INODE_UNINIT, BLOCK_UNINIT, ITABLE_ZEROED]
  Checksum 0xeabf, unused inodes 8144
  Block bitmap at 958 (bg #0 + 958), Inode bitmap at 974 (bg #0 + 974)
  Inode table at 2006-2514 (bg #0 + 2006)
  32768 free blocks, 8144 free inodes, 0 directories, 8144 unused inodes
  Free blocks: 65536-98303
  Free inodes: 16289-24432

没有 Superblock backup。也没有 GDT、RGDT（组描述符表和预留）
Bitmaps 和 inode Table 都在 BG #0

BG #2 属于 Type 3-rest。

接下来我们看看在下一个 Flex BG 的 BG #16：

Group 16: (Blocks 524288-557055) [INODE_UNINIT, ITABLE_ZEROED]
  Checksum 0x8ab4, unused inodes 8144
  Block bitmap at 524288 (+0), Inode bitmap at 524304 (+16)
  Inode table at 524320-524828 (+32)
  24592 free blocks, 8144 free inodes, 0 directories, 8144 unused inodes
  Free blocks: 532464-557055
  Free inodes: 130305-138448

没有 Superblock backup。也没有 GDT、RGDT（组描述符表和预留）
存储了 Flex BG 中所有 BG（#16-#31）的 Bitmaps 和 inode Tables

BG #16 属于 Type 3-head.

到这里，所有的分类都看过一遍了。

上面每个组的第一行最后都有几个 flag，它们通过节省初始化的时间来加速 mkfs 。
INODE_UNINIT^[3]：inode Table 不清零。在被使用的时候，它们会自然地被覆盖。
ITABLE_ZEROED：inode Bitmap 会被清零。它们标识了 inode Table 中的使用情况，所以是必须初始化的。
BLOCK_UNINIT：数据块未初始化。等到有数据来的时候直接覆盖就好。
这其实就是懒惰初始化。
这些特性是被 filesystem feature uninit_bg 决定的。参见 Superblock。

1.这里原文写成了 Logical Block，实际上是 Sector 也就是扇区。注意与 Block 相区别。 ↩
2.Error：原文此处是 “since only the first block of Flex Group...” 应为 “first block group of”
Warning：文章证明了 1 总是 head，接下来又要证明 2 不可能是 head。说实话应该首先论证这两个不可能，然后提出 Type 3 可以划分，而不是先划出 3 个新的再取消其中两种。看的头昏。 ↩
3.原文下面这段描述是错的。这里改过来了。原文如下：
INODE_UNINIT: inode Bitmap is not zeroed, because it can be calculated on-the-fly (e.g. no inodes are used so all of them are free).
ITABLE_ZEROED: inode Bitmap is zeroed.
BLOCK_UNINIT: Data Block Bitmap is not zeroed. (e.g. no data stored so all of them are free). ↩