存储 · XB 现场笔记

LVM 快照在时间上定格一块块设备

Mon, 10 Apr 2028 00:00:00 +0000

LVM 快照既不是拷贝，也不是 reflink：它是一个挂在源逻辑卷上的、大小固定的写时复制异常存储。lvcreate -s -L 5G -n snap vg/data 从卷组里划走 5 GiB，之后 device-mapper 的 snapshot 目标会在某个源 chunk 第一次被写时，把它的原始内容记录下来。无论源卷多大，创建都是瞬时的，因为创建时什么都没复制。

这个大小就是你全部的安全余量，也正是最常被写错的参数。按“一周内没什么写入”配的存储，会被一次数据库 checkpoint 或一次 rsync 在一小时内吃光；而它填满时快照不会降级，而是直接失效并开始返回 I/O 错误。恢复点恰好在你最需要它的那一刻消失，所以存储的剩余空间该进监控面板，而不是躺在 runbook 里。

异常存储，不是副本

一个经典的 LVM 快照用到两个 device-mapper 目标：源卷被重新映射为 snapshot-origin，另有一个新的 snapshot 设备把它与 COW 设备组合起来。读未改动的 chunk 直接落到源卷；某个 chunk 第一次被写时，旧 chunk 被复制进 COW 设备，然后新数据才写下去。所以消耗量跟“发生过改动的不同 chunk 数”成正比，而不是跟写入次数成正比：fixture 往 16 个热 chunk 写了一百万次，只消耗 15 个异常，约 60 KiB。

用 lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size 观察它。经典快照的 lv_attr 是 swi-a-s---：s 表示快照、w 表示可写，而状态位在存储耗尽时会变成 I。data_percent 是存储的填充度，这才是该告警的数字，阈值取 70% 或 80%；100% 不是警告，是讣告。--chunksize 决定异常存储的粒度：粒度越大，块映射表的元数据越省，但每一次改动要拷贝的旧数据也越多。快照还有效时可以用 lvextend 扩容 COW 设备；lvchange --monitor y 则让 dmeventd 自动做这件事。

耗尽即失效

内核文档说得很直白：COW 设备往往比源卷小，一旦填满，快照就变得无用并被禁用，开始返回错误。LVM 给出的容量经验是按预期写入量规划——常常取源卷的 20%——并在填满之前扩容。另外，存储里有一小块要用来存放 COW 块映射表，所以可用于数据的容量略小于 -L 的数值。

影响范围很窄，但时机很残忍：源卷照常运行，所以在读取该快照的备份任务失败之前，或者在你要用的那次回滚已经不可用之前，看不出任何异常。它没有中间状态：到了 100%，正确的心理模型是这份快照从未存在过。

合并回滚，以及 thin 如何改变失败形态

lvconvert --merge vg/snap 把快照中改动过的 chunk 合并回源卷，合并在后台进行，期间源卷仍然可用——对尚未合并的 chunk 的写入会被推迟。约束在源卷一侧：建立合并时它必须处于非活动状态，所以要么先卸载，要么先安排合并、之后再激活源卷。合并只对持久化快照有效，临时快照走不了这条路；合并会消耗掉这份快照，所以需要的东西先拷出来。

thin 快照改变的是失败形态，而不是消除失败。当源是 thin LV 且不给大小时，创建出来的就是 thin 快照；它共享 thin 池里的块，而不拥有自己的存储，所以它自身的分岔无法让它失效。此时共享资源变成了池：池一旦耗尽，坏掉的不是一份快照，而是池里所有 thin 卷，而 LVM 明确警告池可能因此损坏、且难以甚至无法修复。thin_pool_autoextend_threshold 与 dmeventd 的存在，正是因为池耗尽是一次池级事故。

坏掉的样子

最经典的是“备份悄悄不再是备份”。任务挂载快照开始拷贝，拷贝耗时超过了存储能覆盖的时长，存储在某刻到达 100%；快照随即失效，拷贝失败——更糟的情况是，监控只看任务的退出码，而任务读的早就是一个过期的挂载点。所以要盯每一个快照 LV 的 data_percent，70% 就告警，并且按保留窗口内最忙的那一小时来定容量，而不是按平均值。

第二种是“要用的时候合并不了”。lvconvert --merge 要求源卷处于关闭状态，而团队往往是在事故当中才发现这一点。合并开始后由 snapshot-merge 目标接管源卷，dmsetup status 里的已分配扇区数会持续下降，降到只剩元数据就表示合并完成。先在一个一次性卷上演练合并，另留一份不依赖快照的真实备份，并记住：存储已满的快照根本无法合并。

快速验证

在信任这份快照之前，先看存储的填充度：

lvs -a -o lv_name,vg_name,lv_attr,origin,data_percent,lv_size
lvs -a -o lv_name,data_percent,metadata_percent vg/thinpool
dmsetup status vg-snap
lvextend -L +2G vg/snap

data_percent 就是 COW 存储的填充度，健康的快照应当远低于 100；lv_attr 里出现状态位 I 说明快照已经失效。对 thin 快照而言，该看的是池上的 data_percent 与 metadata_percent；dmsetup status 会给出已分配扇区与总扇区之比，可以据此实时观察一次合并把扇区数排空的过程。

来源

lvcreate(8)，说明 -s/--snapshot、COW 与 thin 快照的区别以及容量建议，已核验 2026-09-16。
lvs(8)，定义 lv_attr 状态位，含无效快照，已核验 2026-09-16。
Device-mapper snapshot 支持，异常存储、失效语义与 lvconvert --merge 行为，已核验 2026-09-16。
lvmthin(7)，thin 快照、池耗尽与自动扩容，已核验 2026-09-16。

ZFS 快照给文件系统一个回退键

Tue, 21 Mar 2028 00:00:00 +0000

ZFS 快照就是给某个数据集在某个 transaction group 上的块树起的一个名字。它不复制任何东西、不冻结任何东西，代价只是几个元数据块：zfs snapshot tank/data@before-upgrade 会在 shell 提示符重画完之前就返回。由于 ZFS 从不原地覆盖仍在使用的块，旧块树在磁盘上一直有效，直到最后一个引用消失——而快照就是这个引用。

正是这一点让“一墙的每日历史”变得可行，也正是本文标题最危险的地方。快照给你数据的许多个版本，却不给你“池不会丢”这件事的保障。tank/data 的每一份快照都住在 tank 里，所以带走池的那次故障，会在同一瞬间带走数据集和它的全部历史。多版本与多版本安全是两种不同的性质，后者只能由复制来提供。

为一个一致的树命名

快照建立在 transaction group 边界上，所以它捕获的树内部自洽——数据库的文件与元数据冻结在同一瞬间，而不是相差几微秒。-r 会连同所有后代数据集一起打快照，凡是有子数据集的地方都该这么用；否则一个递归布局会在不同层级留下时间不同的快照，层与层之间的增量复制就变得别扭。

名字由你决定，而它是保留策略唯一的抓手：tank/data@daily-2026-09-16 可以按模式清理，自动生成的名字则需要额外记账。zfs list -t snapshot -o name,used,refer,creation -s creation 列出整个快照集以及每一份钉住的空间。

空间在哪里：zfs list -o space

ZFS 用一组列来回答唯一重要的问题：这是谁的数据？zfs list -o space tank/data 会给出 USED、USEDSNAP、USEDDS、USEDREFRESERV、USEDCHILD、REFER 与 AVAIL。REFER 是数据集自身需要的量，USEDSNAP 是快照钉住的量，USED 是二者之和。USEDSNAP 持续上涨而 REFER 保持不变，说明吃掉池子的是快照，不是数据。具体到某一份快照，used 是它单独钉住的块，refer 是它能引用到的全部块，两者之差正是与其他版本共用的那部分。

fixture 在 64 MiB 的数据集上搭了一墙 30 份每日快照，每天翻动 2 MiB。每一次创建都花费 0 KiB——代价落在紧随其后的那次写入上，重写 2 MiB 就是 2048 KiB——整墙历史的代价是 60 MiB，而 30 份完整拷贝需要 1920 MiB。这个比例就是快照存在的全部理由，也解释了为什么池子直到快满才有人注意到。反过来，当池子告急时，该做的第一件事是按 zfs list -t snapshot -o name,used 倒序找出钉住空间最多的那一份。

hold、diff 与版本对比

hold 是一个具名引用，它让销毁以 EBUSY 失败：zfs hold keep tank/data@daily-2026-09-16 保护一份快照，zfs holds 列出持有者，zfs release keep 解除。备份软件会给正在发送的那份快照加 hold，免得保留脚本把它删掉；代价是保留任务会一直以“快照忙”失败，直到 hold 被释放，而一个卡住的 hold 能让一份快照被钉住好几个月。

zfs diff tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 按路径报告变化——+ 新建、- 删除、M 修改、R 重命名——并且两份快照都必须仍然存在，所以对比昨天很容易，对比上个月未必。要看快照里的内容，走数据集下隐藏的 .zfs/snapshot/<名字> 目录；快照没有单独的挂载点，而 snapdir=visible 能让这个目录被列出来。

坏掉的样子

真正要紧的失败，恰恰是标题诱导你去相信的那种：池丢了。控制器故障、背板故障或者池级损坏，会原子地删掉数据集以及它的每一份快照，没有部分幸存这回事。唯一的防线是池外的那份拷贝：zfs send -i tank/data@yesterday tank/data@today | zfs receive backup/data 会把一条独立、带校验和的流写进第二个池，只有它能挺过第一个池的死亡。一墙快照却没有副本，是换了个好看界面的单点故障。池内的冗余（镜像、RAIDZ）与 scrub 解决的是另一类问题——坏盘与静默损坏——它们替代不了池外副本，因为控制器或背板故障会把同一个池里的冗余一起带走。

第二种是空间悄悄爬升、保留任务却跑不动。USEDSNAP 上涨而 REFER 不动，池越过 80%，随后 ZFS 开始以“空间不足”拒绝写入，尽管从数据集上看一切正常——池的 slop 与预留量在文件系统内部根本看不见。如果某份快照还被某个 clone 钉住，销毁会失败；而要回滚到 clone 的源之前，就必须连带递归销毁那个 clone。长寿命的 hold 会把保留策略变成一张依赖图，所以 hold 的存活时间要短、要可审计。

快速验证

看清快照的代价，以及它们能不能被删掉：

zfs list -t snapshot -o name,used,refer,creation -s creation tank/data
zfs list -o space tank/data
zfs holds tank/data@daily-2026-09-16
zfs diff tank/data@daily-2026-09-15 tank/data@daily-2026-09-16
zfs send -i tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 | zfs receive backup/data

每份快照的 used 是它单独钉住的空间，刚创建的快照应接近零；space 那组列则给出数据集上的 USEDSNAP 与 REFER，USEDSNAP 上涨而 REFER 不变就是该清理的信号。若 zfs destroy 报快照忙，zfs holds 会告诉你要释放哪个 tag。最后一条是唯一能防住池丢失的操作，应该定时执行。

来源

zfs-snapshot(8)，快照创建语义与递归快照，已核验 2026-09-16。
zfs-list(8)，space 列集，含 USEDSNAP、USEDDS 与 REFER，已核验 2026-09-16。
zfs-hold(8)，hold、zfs holds 以及销毁返回的 EBUSY，已核验 2026-09-16。
zfs-send(8)，把数据送出本池的增量复制流，已核验 2026-09-16。

高基数标签在查询之前就增加存储序列

Mon, 10 Jan 2028 00:00:00 +0000

Prometheus 序列由指标名与完整标签集合识别。在计数器上增加客户或请求身份，即使所有面板都会立刻把这些身份求和，也仍可能创建大量序列。查询聚合改变返回结果，不会删除已经入库的原始序列。存储和写入成本在用户打开面板之前就已经产生，因此不能只看面板返回多少行来判断仪表化是否足够节制。

统计实际组合，而不是孤立取值

一个新的标签值，不是在整个数据库中自动对应一条新序列。它在指标名及其他标签形成不同组合的位置上，分别构成新身份。在明确指标与目标范围内，可能取值数的乘积给出笛卡尔组合上界；只有每种组合实际出现时，它才等于观测数量。维度之间存在约束时，上界可能远大于现实。真实数量还受到目标标签与指标族形态影响，不能把理论乘积直接宣称为已经发生的序列数量。

来自少量路由模板的标签可以有边界，包含标识符和查询参数的完整 URL 往往没有。客户身份、请求编号、任意错误文本和时间戳也需要明确审视。带多个桶序列的直方图，还会进一步放大每组标签组合的影响。预算应依据真实输出和预期工作负载，而不是只看某一个维度有多少取值，也不能因为每条样本数值很小便忽略身份成本。

查询少几行，不代表少存几行

按路由求和的表达式，可以读取十二条客户级序列后只返回三个结果，但十二条输入仍然存在。如果指标契约需要的就是路由总量，仪表化可以直接维护路由级计数器，只导出三条序列。这是在源头减少输出身份，不是要求每个消费者都重复隐藏额外维度。两种方式可能显示相同总数，却具有不同的数据保留和成本含义。

入库时删除标签不等于完成上述累计。不同样本可能获得同一个身份，而重新标记不会替它们决定如何相加。应使用明确的仪表化变更，或定义清楚的记录查询；后者会新增派生序列，原始数据仍按照存储策略保留。确实需要详细关联时，可以放入日志或追踪，但它们同样需要各自的权限、保留期限与成本约束，不是完全没有代价的替代存储。

使用正确范围的清单诊断增长

TSDB 状态接口提供头部统计，其中包括按指标名汇总的序列数量。这些值有助于定位大型指标族，但不是完整成本模型。采样间隔、标签长度、身份更替、数据块处理、保留策略和存储行为都会影响资源。不能把一个小实验中减少的序列比例，直接换算成生产内存或磁盘会减少的相同比例，更不能把该比例当成容量压测结果。

当一些头部序列已经没有近期可选择样本时，即时查询计数与头部序列统计可能不同；历史存储块又是另一种范围。比较报告时应记录测量时刻和统计总体。某次发布改变标签值后，旧身份仍可能留在存储中，因此查询当前返回更少结果，不代表之前的全部成本都已经消失。需要分别观察新增速度、当前可见序列和保留历史。

每次抓取的样本上限是保护措施，不是选择性聚合。指标重新标记之后仍超过该上限时，Prometheus 会把整个抓取视为失败，并不是悄悄保留一个便宜的子集。因此，保护资源的同时也可能失去有用观测。应根据真实输出制定预算，并对抓取失败设置清楚的信号，不能把限制触发后的缺失误解成业务没有流量。

坏掉的样子

新增无边界标签可能持续增加写入与内存压力，直到抓取或查询受到影响。应先定位指标族与仪表化改动，再从源头或经过审阅的样本过滤策略阻止不必要的新身份。立即删除历史数据不是所有场景都必须采用的恢复步骤，改变保留时间也不会瞬间清除全部资源成本。处理方式应依据实际瓶颈，而不是套用统一删除命令。

更隐蔽的失败是查询聚合很成功，面板看起来很小，但原始指标仍持续增长。应同时审阅导出身份和查询输出，为新增维度说明预期取值范围、有用消费者与负责人。生产计数器速率查询还应保留正确的重置处理；本实验用于比较固定总量的即时求和，不能代替先求速率再聚合的运行监控语义。

快速验证

保存程序为 cardinality.py，执行 python3 cardinality.py。需要 Docker 与 Prometheus 3.5.1，必要时下载镜像。本地文本端点为三个路由分别导出四个合成客户身份，同时独立导出已经累计好的路由总量。真实服务器抓取这些样本，并提供查询结果与 TSDB 统计，实验不会使用任何真实客户信息。

import http.client
import io
import json
import subprocess
import time
import uuid
from urllib.parse import quote

name = "xbcatm-monitoring-" + uuid.uuid4().hex[:12]


class ResponseSocket:
 def __init__(self, data):
 self.data = data

 def makefile(self, mode):
 return io.BytesIO(self.data)


def request(method, path, body="", content_type="application/json"):
 body = body.encode()
 headers = (f"{method} {path} HTTP/1.1\r\nHost: 127.0.0.1:{port}\r\n"
 f"Connection: close\r\nContent-Type: {content_type}\r\n"
 f"Content-Length: {len(body)}\r\n\r\n").encode()
 result = subprocess.run(
 ["docker", "exec", "-i", name, "/bin/nc", "-w", "3", "127.0.0.1", str(port)],
 input=headers + body, capture_output=True, timeout=5,
 )
 if result.returncode:
 raise RuntimeError(result.stderr.decode())
 response = http.client.HTTPResponse(ResponseSocket(result.stdout))
 response.begin()
 return response.status, response.read().decode()


def get_json(path):
 status, body = request("GET", path)
 assert status == 200, (status, body)
 return json.loads(body)


def eventually(check):
 for attempt in range(150):
 try:
 value = check()
 if value:
 return value
 except (RuntimeError, AssertionError, http.client.HTTPException):
 pass
 time.sleep(0.1)
 raise AssertionError("Expected local server state did not appear")


def query(expression):
 response = get_json("/api/v1/query?query=" + quote(expression, safe=""))
 assert response["status"] == "success"
 return response["data"]["result"]


def value(expression):
 result = query(expression)
 assert len(result) == 1, (expression, result)
 return float(result[0]["value"][1])

port = 9090
# Requires Docker and the Prometheus 3.5.1 image.
script = r"""set -eu
mkdir -p /tmp/www /tmp/targets
cat > /tmp/prom.yml <<'PROM_CONFIG'
global:
 scrape_interval: 1s
 scrape_timeout: 500ms
scrape_configs:
 - job_name: cardinality
 metrics_path: /metrics.txt
 static_configs:
 - targets: ['127.0.0.1:8080']

PROM_CONFIG
cat > /tmp/www/metrics.txt <<'METRIC_DATA'
# TYPE raw_requests_total counter
# TYPE bounded_requests_total counter
raw_requests_total{route="/orders",customer_id="synthetic-1"} 1
raw_requests_total{route="/orders",customer_id="synthetic-2"} 2
raw_requests_total{route="/orders",customer_id="synthetic-3"} 3
raw_requests_total{route="/orders",customer_id="synthetic-4"} 4
bounded_requests_total{route="/orders"} 10
raw_requests_total{route="/cart",customer_id="synthetic-1"} 1
raw_requests_total{route="/cart",customer_id="synthetic-2"} 2
raw_requests_total{route="/cart",customer_id="synthetic-3"} 3
raw_requests_total{route="/cart",customer_id="synthetic-4"} 4
bounded_requests_total{route="/cart"} 10
raw_requests_total{route="/search",customer_id="synthetic-1"} 1
raw_requests_total{route="/search",customer_id="synthetic-2"} 2
raw_requests_total{route="/search",customer_id="synthetic-3"} 3
raw_requests_total{route="/search",customer_id="synthetic-4"} 4
bounded_requests_total{route="/search"} 10

METRIC_DATA
/bin/httpd -f -p 127.0.0.1:8080 -h /tmp/www > /tmp/httpd.log 2>&1 &
exec /bin/prometheus --config.file=/tmp/prom.yml --storage.tsdb.path=/tmp/data --web.listen-address=127.0.0.1:9090
"""
try:
 subprocess.run(
 ["docker", "run", "-d", "--rm", "--name", name, "--network", "none",
 "--entrypoint", "/bin/sh", "prom/prometheus:v3.5.1", "-c", script],
 check=True, capture_output=True, text=True, timeout=20,
 )
 eventually(lambda: len(query('raw_requests_total')) == 12)
 assert value('count(raw_requests_total)') == 12
 assert value('count(bounded_requests_total)') == 3
 assert value('sum(raw_requests_total)') == value('sum(bounded_requests_total)') == 30
 raw_by_route = {x["metric"]["route"]: float(x["value"][1])
 for x in query('sum by (route) (raw_requests_total)')}
 bounded_by_route = {x["metric"]["route"]: float(x["value"][1])
 for x in query('bounded_requests_total')}
 assert raw_by_route == bounded_by_route
 statistics = get_json('/api/v1/status/tsdb')["data"]
 counts = {x["name"]: x["value"] for x in statistics["seriesCountByMetricName"]}
 assert counts["raw_requests_total"] == 12 and counts["bounded_requests_total"] == 3
 print(json.dumps({"raw_series": 12, "bounded_series": 3, "snapshot_total": 30,
 "per_route": raw_by_route, "tsdb_counts_confirmed": True}, indent=2))
finally:
 subprocess.run(["docker", "rm", "-f", name],
 stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

断言确认原始表示有十二条序列，受控表示有三条，两者总量都为三十，每个路由合计十。执行查询聚合之后，TSDB 仍报告十二条原始序列，证明返回结果变小没有擦除输入。隔离容器没有外部网络、宿主机挂载或公开端口，退出时删除。结果验证身份数量和算术，不是生产容量基准。

本轮没有修改此运行实验，也没有重新执行。文中的预期输出和此前记录的观察，与本轮执行证据分别保留，不能据此声称真实集成已经再次通过。

来源

Prometheus: data model，序列身份由指标名与标签集合组成，已核验 2026-10-15。
Prometheus: metric and label naming，受控维度与高基数标签建议，已核验 2026-10-15。
Prometheus: storage，头部数据、存储块与保留成本，已核验 2026-10-15。
Prometheus: HTTP API，按指标名称查看头部序列统计，已核验 2026-10-15。
Prometheus：配置，每次抓取的样本上限与重新标记冲突边界，已核验 2026-10-15。

checkpoint 把脏缓冲刷到磁盘

Thu, 06 Jan 2028 00:00:00 +0000

检查点为 PostgreSQL 崩溃恢复建立一个可用起点。它同步这个检查点所需的数据文件变更，并记录相应恢复信息。依赖某段日志的数据页写出之前，相关 WAL 必须先持久化。这样的顺序让事务提交不必每次都把全部修改过的表页立即刷到磁盘；发生崩溃时，再从恢复起点重放后续必要变更。

坏掉的样子

检查点不是事务提交。数据页可以包含尚未提交事务写入的版本，读者究竟能看到哪些行，仍然由可见性与事务状态决定。检查点完成，不会把这些写入变成已提交，也不会把随手复制一份正在变化的数据目录变成有效基础备份。并发活动还可能再次弄脏页面，所以不能把完成提示理解成缓冲池从此全部干净。

日志保留也有别的限制。最大 WAL 大小是与自动检查点调度有关的软目标，不是磁盘使用硬上限；归档失败或复制槽保留，都可能让日志超过这个值。最小 WAL 大小则涉及回收并预留文件供以后复用，不是另一条强制触发检查点的阈值。如果理解错这些参数，可能一边看到检查点间隔正常，一边忽略实际上还在持续增长的归档积压。

快速验证

准备一台安静的 PostgreSQL 18 可丢弃实例，开启甲、乙两个全新的 psql -X -v ON_ERROR_STOP=1 会话。显式检查点和控制文件信息使用具有相应权限的管理角色。保留正常开启的同步落盘与同步提交设置。乙先创建计数器，并保存当前检查点位置：

SHOW fsync;
SHOW synchronous_commit;
CREATE SCHEMA checkpoint_demo;
CREATE TABLE checkpoint_demo.items (id integer PRIMARY KEY,n integer);
INSERT INTO checkpoint_demo.items VALUES (1,10);
CREATE TABLE checkpoint_demo.baseline AS
SELECT checkpoint_lsn FROM pg_control_checkpoint();

显示的两个设置都应为开启，初始已经提交的值是十。甲在一个保持打开的事务中把它改成九十九：

BEGIN;
UPDATE checkpoint_demo.items SET n=99 WHERE id=1 RETURNING n;

甲从自己的更新得到九十九，但此时不要提交。乙请求检查点，并查看普通读者可见的值：

CHECKPOINT;
SELECT c.checkpoint_lsn>b.checkpoint_lsn AS checkpoint_advanced,
 (SELECT n FROM checkpoint_demo.items WHERE id=1) AS visible_value
FROM checkpoint_demo.baseline AS b CROSS JOIN pg_control_checkpoint() AS c;

检查点位置推进了，乙仍然读到十。维护工作已经完成，甲的事务却还没有决定提交还是回滚。这把数据库维护的进度与业务操作的提交状态明确区分开来，不能把其中一个完成信号当成另一个完成的证据。回到甲，核对自己的版本仍然可见，然后丢弃这次修改：

SELECT n FROM checkpoint_demo.items WHERE id=1;
ROLLBACK;

甲回滚前仍读到九十九。乙现在确认值恢复为原来的十，再完成一次普通提交，并在这次操作紧邻的位置记录前后检查点标识：

SELECT n FROM checkpoint_demo.items WHERE id=1;
UPDATE checkpoint_demo.baseline
SET checkpoint_lsn=(SELECT checkpoint_lsn FROM pg_control_checkpoint());
UPDATE checkpoint_demo.items SET n=11 WHERE id=1;
SELECT c.checkpoint_lsn=b.checkpoint_lsn AS no_new_checkpoint,
 (SELECT n FROM checkpoint_demo.items WHERE id=1) AS committed_value
FROM checkpoint_demo.baseline AS b CROSS JOIN pg_control_checkpoint() AS c;
DO $$ BEGIN
 IF (SELECT n FROM checkpoint_demo.items WHERE id=1) IS DISTINCT FROM 11 THEN
 RAISE EXCEPTION 'checkpoint/transaction boundary result mismatch';
 END IF;
END $$;
DROP SCHEMA checkpoint_demo CASCADE;

本次短调度的结果先是十，随后检查点未变化的比较为真，已经提交的值是十一。普通提交成功，并没有请求另一个检查点。在繁忙实例里，独立调度的检查点可能恰好改变这个比较结果，但不会改变提交本身的语义。断言核对最终行值，实验结束后删除自己的模式。

原演练报告的是事务可见性与检查点边界；本轮审阅没有重新执行双会话调度，没有测量恢复耗时，也没有模拟存储设备丢失已经确认写入的情况。持久性契约仍然依赖正确开启的相关设置，以及能够履行同步请求的存储。要判断实际恢复时间是否满足目标，需要另做基于真实保留工作量的崩溃恢复演练，不能从这几条查询完成得快直接推导出来。

同时考虑恢复与前台负载

延长检查点间隔，可能减少重复刷写，并在开启整页写入时减少一部分重复整页日志；崩溃后需要重放的工作也可能随之增加。检查点过于频繁，又可能提高日志和数据写流量，影响请求延迟。存储是快速本地磁盘，并不能单独证明更长的间隔就符合业务恢复目标，还是需要以测量作取舍。

完成目标参数把常规检查点工作分散到间隔中的某个比例，常用的九成是节奏目标，不是任何负载下都没有延迟尖峰的保证。应把检查点持续时间、请求触发与定时触发次数、日志增长和前台延迟结合起来看。累计计数应比较同一观察窗口内的增量，并检查 stats_reset；统计重置后数字变小，不代表工作量或故障已经改善。调小参数使任务更快完成，也可能意味着同一批写入挤在更短窗口里，不能只看完成时长缩短就认为代价下降。

在 PostgreSQL 18 中，检查点计数和写入、同步时间位于专门的检查点统计视图；后台写进程视图描述的是另一个组件。频繁由日志增长触发请求时，先判断是正常写入量、配置目标还是保留链路造成，再修改限额。最终应比较恢复测试和业务延迟，让调优结论对应实际达到的恢复能力，而不是只对应一个看起来整齐的参数值。

来源

PostgreSQL 18 WAL 入门，预写顺序及无需立即刷出所有数据文件的提交持久性，已核验 2026-10-15。
PostgreSQL 18 CHECKPOINT，显式检查点行为与所需权限，已核验 2026-10-15。
PostgreSQL 18 WAL 配置，检查点调度、写入节奏和日志大小语义，已核验 2026-10-15。
PostgreSQL 18 累计统计，专门的检查点统计视图，已核验 2026-10-15。

分区把一张表拆成很多看起来还像一张的片段

Thu, 23 Dec 2027 00:00:00 +0000

声明式分区让 PostgreSQL 对外提供一张逻辑表，同时把行存放在不同分区中。父表负责写入路由，并作为统一查询入口；真正持有数据的是物理分区。它的主要收益往往来自生命周期管理和选择性访问，但选择分区时，也会影响键、查询形态和运维锁，不能只把它看作拆文件。

逻辑父表与物理子表

分区父表本身没有行存储。每个已挂载分区保存符合边界的行，可以有自己的存储参数、索引和维护活动。分区索引也类似，是各物理分区索引的集合，并不是在父表上再保存一整份相同数据。理解这一点，有助于区分统一入口与实际占用磁盘的关系。

范围、列表和哈希分区使用不同划分规则。应根据真实访问和保留要求选择键：按月保存事件可能适合范围分区，其他负载可能需要不同分布。声明式分区本身不会把这些分区自动分散到独立数据库服务器。本地分区仍共享所在数据库的资源和事务环境，不能因为表被拆开，就推断它已经实现分布式分片。

保持父表名字稳定，可以简化应用入口，但不能证明应用代码完全不用改。查询需要暴露适合的分区键限制，才可能从裁剪受益；主键与外键引用也可能需要重新设计。原本按全局唯一标识操作的调用，必须保留同样的身份语义，不能在物理拆分过程中悄悄改变其含义。

分区键不只影响路由

分区表上的唯一或主键约束必须包含全部分区键列，而且这些约束要求分区键不含表达式。各分区的独立索引，不能自行证明其他分区中不存在相同键。因此，day 与 id 的复合主键，并不保证 id 在不同日期之间仍然全局唯一。

从单表全局 id 主键迁移时，这个差别尤其重要。只是把日期加入主键，可能弱化原有身份契约。更改之前，应检查调用方、引用关系和重复防护要求。分区键不是可以完全脱离公开数据模型进行调整的纯物理参数，否则原来按 id 更新一行的操作，可能开始匹配多行。

修改分区键可以把行移动到另一个分区。目标分区必须存在并接受该行，索引和约束仍然生效。这是真实数据变更，不是免费的元数据修改。如果保留策略已经移除了目标范围，迟到的修正可能失败，即使逻辑父表仍然存在。生命周期设计应同时考虑正常新增和历史更正。

坏掉的样子

DETACH 把一张表从分区层级移除，但保留该表及其数据。通过父表查询时不再看到它，脱离后的关系仍可单独检查或导出。DROP 则会连同分区数据一起删除。脱离不等于删除，这两种操作也都不会自动生成已经验证过的归档或备份，不能因为维护命令成功就认定数据已妥善保留。

分区维护需要锁。普通 detach 需要父表上的强锁，可能等待长时间运行的操作，也会影响并发访问。PostgreSQL 提供锁行为不同的并发脱离形式，但有额外限制，例如不能放在显式事务块中执行，也不能用于包含 DEFAULT 分区的父表。并发脱离若被中断，还可能需要 FINALIZE 才能完成后续维护。应按照实际契约选择操作，不能把“元数据操作”理解为“一定不会阻塞”。

分区过多也会增加规划和内存成本，没有一个普遍适用的行数阈值能证明分区一定划算。应测量有代表性的读取和维护操作，在写入需要前创建未来分区，并明确迟到数据与保留策略如何配合。对于较小且索引合理的表，大量细碎分区可能只增加管理工作，而没有带来足够收益。

快速验证

把下面内容保存为 partition-lifecycle.sql，在可丢弃的 PostgreSQL 18 数据库中执行 psql -X -v ON_ERROR_STOP=1 -f partition-lifecycle.sql。实验使用临时分区和普通事务内 detach，最后回滚移除整个测试环境。

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE events (day date,id integer,PRIMARY KEY(day,id)) PARTITION BY RANGE(day);
CREATE TEMP TABLE events_sep PARTITION OF events FOR VALUES FROM ('2026-09-01') TO ('2026-10-01');
CREATE TEMP TABLE events_oct PARTITION OF events FOR VALUES FROM ('2026-10-01') TO ('2026-11-01');
INSERT INTO events VALUES ('2026-09-15',1),('2026-09-30',2),('2026-10-01',3);
SELECT id,day,tableoid::regclass AS physical_table FROM events ORDER BY id;
DO $$ BEGIN
 CREATE UNIQUE INDEX events_id_only ON events(id);
 RAISE EXCEPTION 'global id uniqueness accepted without partition key';
EXCEPTION WHEN feature_not_supported THEN RAISE NOTICE 'unique key must include partition key';
END $$;
SAVEPOINT id_scope;
INSERT INTO events VALUES ('2026-10-03',1);
SELECT id,day FROM events WHERE id=1 ORDER BY day;
ROLLBACK TO id_scope;
RELEASE id_scope;
UPDATE events SET day='2026-10-02' WHERE id=2;
SELECT id,day,tableoid::regclass AS physical_table FROM events ORDER BY id;
ALTER TABLE events DETACH PARTITION events_sep;
SELECT (SELECT count(*) FROM events) AS attached_rows,(SELECT count(*) FROM events_sep) AS detached_rows;
DO $$ BEGIN
 IF (SELECT array_agg(id ORDER BY id) FROM events) IS DISTINCT FROM ARRAY[2,3] OR
 (SELECT array_agg(id ORDER BY id) FROM events_sep) IS DISTINCT FROM ARRAY[1] THEN
 RAISE EXCEPTION 'detach changed stored rows';
 END IF;
END $$;
ROLLBACK;

本轮 PostgreSQL 18.6 单用户 SQL 重跑把标识一、二路由到九月，把标识三路由到十月；未测试客户端传输和并发脱离。数据库还拒绝在父表上只按 id 建立唯一索引。在保存点内，另一天的第二个 id 一可以按复合主键规则成功插入；回滚该保存点后，数据恢复到初始状态。这个结果直接展示复合唯一性与单列全局唯一性的差别。

修改标识二的日期后，tableoid 显示它已移动到十月。脱离九月分区后，父表可见两行，脱离的表仍保存一行。断言检查两侧确切的标识集合，证明 detach 改变的是成员关系，并没有丢弃存储数据。这里验证生命周期与键语义，没有测量生产锁持续时间，也不能替代完整的归档流程。

来源

PostgreSQL 表分区，物理存储、键、路由和分区管理，已核验 2026-10-15。
PostgreSQL ALTER TABLE，挂载、脱离行为与锁限制，已核验 2026-10-15。

Redis AOF 用速度换持久性

Wed, 17 Nov 2027 00:00:00 +0000

AOF 记录 Redis 的数据变更，供启动时恢复，但选择 AOF 并不等于承诺任何已确认写入都绝不会丢失。持久性取决于 fsync 策略、实际生效的配置、底层存储，以及讨论的是进程退出、操作系统崩溃还是整块磁盘损坏。应该先明确恢复目标，再决定日志策略，不能仅凭“追加日志”这个名称推导保证。

执行、记录与确认不是同一步

Redis 先在内存数据集上执行命令，再把需要持久化的效果传播到 AOF。它不是“每条命令必须先落盘才能修改内存”的执行模型。使用 appendfsync always 时，Redis 在发送回复前同步追加的数据；一起处理的命令可以共用一次写入和 fsync，并不必然每个客户端命令都对应一个独立系统调用。

执行成功、完成同步、客户端收到回复仍是不同的时刻。连接在回复到达前断开，客户端不能据此判断操作没有发生，也不能因为配置了 always 就放心重复执行扣减或计数操作。持久化协议并没有替业务提供重试去重。

AOF 是用于重建状态的表示，不是永久保存所有原始请求的审计流水。Redis 可以转换用于持久化的命令，重写也只保留重建当前数据所需的信息，而非完整历史。因此，已经删除的值并不保证还能从重写后的文件中找回来。

按确认语义选择同步策略

appendfsync everysec 大约每秒安排同步，通常以约一秒的写入暴露窗口换取性能，但不能把它当成任意存储阻塞下都成立的严格丢失上界。appendfsync no 则把刷盘时机交给操作系统；它表示 Redis 不主动请求 fsync，不表示数据永远不会落到磁盘。这两种策略下，一条成功回复都不等于该写入已经进入稳定存储。

appendfsync always 给出更强的本机写入确认约定，同时增加同步开销，影响延迟与吞吐。它仍不能保护磁盘整体丢失、存储栈失信或应用主动误删。还要检查 no-appendfsync-on-rewrite：如果将其打开，后台持久化工作期间会暂停通常的 fsync，即使主要策略写着 always，实际保证也会变弱。检查有效配置比只检查某一个配置项更重要。

重写产物是一组文件

Redis 7 起，AOF 使用 manifest 清单、基础文件和增量文件。启用 aof-use-rdb-preamble 时，基础文件采用 RDB 格式，其后的修改放在增量 AOF 中。这个基础文件属于 AOF 自己的文件集合，不是另外定期生成的 dump.rdb，二者不能因为扩展名相似就混为一谈。

BGREWRITEAOF 的成功回复只表示开始或安排了后台重写，不代表工作已经完成。应结合 INFO persistence 确认重写完成且状态成功。备份时不能只挑一个名字像日志的文件，也不能在重写切换文件期间随意复制目录；要保存彼此一致的 manifest 及其引用的活动文件，才能沿正确顺序恢复。

坏掉的样子

磁盘写入错误、空间耗尽和重写失败都需要告警，配置了 appendonly yes 并不会让这些风险消失。应结合 aof_last_write_status、aof_last_bgrewrite_status、当前重写状态、剩余磁盘空间与应用错误判断健康度。后台任务仍会竞争磁盘，并因写时复制增加内存占用，“后台”不能解释为完全没有前台延迟影响。

日志末尾截断与中部字节损坏的处理语义也不同。检查或修复前应保留原始文件；修复可能丢弃损坏位置之后的命令，不能直接把修复成功当成数据完整。AOF 会忠实保留应用误操作的效果，所以仍需独立留存备份。进程重启成功并不能证明断电安全、复制确认或业务恰好执行一次。

快速验证

准备 POSIX 环境、C 编译器、make、curl、tar 和 Python 3.10 以上版本。本实验已在 macOS、Redis 8.10.1、redis-py 8.1.0、Python 3.14.4 上运行。安装步骤仅以 libc 构建 Redis 核心，并把客户端放入临时虚拟环境，不安装到系统环境。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行下面的 Python 代码。它创建私有 Unix socket，不开放 TCP，不安排自动快照或自动 AOF 重写；AOF 使用 always，重写期间也不跳过同步。代码只杀死自己创建的子进程，持久化文件会在临时目录内保留到重启验证完成，最后清理该目录，不连接默认 Redis。

from contextlib import contextmanager
import os
from pathlib import Path
import signal
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(directory, aof):
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--dir", directory, "--dbfilename", "dump.rdb", "--save", "",
 "--appendonly", "yes" if aof else "no", "--appendfsync", "always",
 "--appenddirname", "appendonlydir", "--appendfilename", "appendonly.aof",
 "--aof-use-rdb-preamble", "yes", "--no-appendfsync-on-rewrite", "no",
 "--auto-aof-rewrite-percentage", "0",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client, process
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode in (0, -signal.SIGKILL), errors.decode()


def crash(process):
 assert process.poll() is None
 process.kill()
 assert process.wait(timeout=5) == -signal.SIGKILL


with TemporaryDirectory(prefix="redis-aof-", dir="/tmp") as directory:
 with instance(directory, aof=True) as (client, process):
 client.set("counter", 0)
 for expected in range(1, 5):
 assert client.incr("counter") == expected
 assert client.hset("profile", mapping={"name": "Ada", "level": "2"}) == 2
 client.set("deleted", "not retained")
 assert client.delete("deleted") == 1
 rewrites = client.info("persistence")["aof_rewrites"]
 assert client.bgrewriteaof()
 deadline = time.monotonic() + 5
 while True:
 state = client.info("persistence")
 if (state["aof_rewrites"] > rewrites
 and not state["aof_rewrite_in_progress"]
 and not state["aof_rewrite_scheduled"]):
 assert state["aof_last_bgrewrite_status"] == "ok"
 break
 assert time.monotonic() < deadline, "AOF rewrite did not finish"
 time.sleep(0.02)
 assert client.incr("counter") == 5
 assert client.info("persistence")["aof_last_write_status"] == "ok"
 assert not (Path(directory) / "dump.rdb").exists()
 print("rewrite completed; a later INCR returned 5; no standalone RDB")
 crash(process)

 aof_dir = Path(directory) / "appendonlydir"
 entries = []
 for line in (aof_dir / "appendonly.aof.manifest").read_text().splitlines():
 parts = line.split()
 entries.append(dict(zip(parts[::2], parts[1::2], strict=True)))
 active = [entry for entry in entries if entry["type"] in {"b", "i"}]
 assert {entry["type"] for entry in active} == {"b", "i"}
 for entry in active:
 assert (aof_dir / entry["file"]).is_file()
 base = next(aof_dir / entry["file"] for entry in active if entry["type"] == "b")
 assert base.read_bytes().startswith(b"REDIS")
 print("manifest references an RDB-format AOF base and an incremental AOF")

 with instance(directory, aof=True) as (client, process):
 assert client.get("counter") == b"5"
 assert client.hgetall("profile") == {b"name": b"Ada", b"level": b"2"}
 assert client.get("deleted") is None
 assert client.dbsize() == 2
 print("after SIGKILL and restart: counter=5, hash restored, deletion retained")

实验先等待一次确实完成且状态成功的重写，再执行一次额外递增。SIGKILL 之后，manifest 引用 RDB 格式的 AOF 基础文件和增量文件，目录内却没有独立 dump.rdb。重新启动同一目录的 Redis，计数器恢复为五，hash 的两个字段都在，已经删除的键仍不存在。验证字段值和数据类型比只比较键总数更有说服力。

清单检查只针对这里生成的简单文件名，不是通用备份解析器。SIGKILL 跳过正常关闭流程，但操作系统仍然运行，文件系统缓存也仍在。因此，该结果证明的是这条本地 AOF 恢复路径，而不是 everysec 或 no 的实测丢失上界，更不是底层硬件故障时的数据保证。

来源

Redis 持久化，同步策略、多文件 AOF、恢复与备份边界，已核验 2026-09-08。
Redis BGREWRITEAOF，安排重写与完成重写的区别，已核验 2026-09-08。
Redis INFO，持久化状态字段，已核验 2026-09-08。
Redis 8.10.1 配置，同步策略、重写期间的覆盖选项与文件布局，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与选择分配器，已核验 2026-09-08。

Btrfs 快照是写时复制，不是复制

Sun, 14 Nov 2027 00:00:00 +0000

btrfs 快照不是任何意义上的复制。btrfs subvolume snapshot 建立的新子卷，其根指向与源完全相同的 extent 树，两边共享的每个 extent 被引用两次、只存一份。创建是一次元数据操作：子卷里装的是 1 GiB 还是 10 TiB，耗时都在毫秒级。

这让快照成为机器上最便宜的回滚原语，也正是它最常被过度信任的原因。空间随分岔增长，而不随数据量增长；代价来得晚，落在别人的写操作上，而且落在保存原始数据的那块设备上。从不清理的快照是一场慢动作的磁盘写满事故，而同盘快照无论留多少份都不是备份。

共享 extent，而不是复制数据块

快照就是子卷，而子卷是拥有自己根的子树，所以快照机制与让 reflink 生效的是同一套引用计数。用 btrfs subvolume snapshot -r /data /snap/data-2026-09-16 打一个只读快照；-r 很关键，因为可写快照在任何一次写入发生的那一刻就开始分岔，而备份目标本来就不该可写。快照与源是平级的子卷，清理用 btrfs subvolume delete /snap/data-2026-09-16；正在被挂载使用的子卷删不掉，btrfs subvolume list -t 能把快照按父子关系列成表，按时间做保留时用得上。

真正花钱的是快照之后的那次写入。任意一侧覆盖一个共享 extent 时，文件系统给写入方分配新 extent，把旧 extent 留给另一侧，所以快照的价格由随后的写入支付，计量单位是这次写入触及的 extent 数，而不是快照命令本身。APFS 的 clonefile 遵循同一规则，fixture 量到的形状是：克隆 64 MiB 花费 0 KiB，普通复制 64 MiB 花费 65536 KiB，覆盖克隆文件前 8 MiB 花费 8192 KiB；而把这 8 MiB 再改写一次花费 0 KiB，因为这些 extent 已经分岔过了。

空间到底去了哪里

btrfs filesystem du 给出诚实的账目：对每个参数打印 Total、Exclusive 与 Set shared，其中 Set shared 是它与命令行上其他子卷共享的空间。刚打完快照时，Exclusive 应接近零，Set shared 接近源的 Total。compsize 按文件给出同样的划分，开了配额后 btrfs qgroup show -reF 按 qgroup 追踪 exclusive 与 referenced 字节。df 在这里帮不上忙：它报的是整个文件系统，无法把空间归属到某个子卷或某一份快照，这正是需要 du 与 qgroup 的原因。

删掉源并不会释放共享 extent——它们变成快照的独占数据，空间只是换了主人。这是关于 btrfs 最常见的求助：文件删了，df 不动。只有当最后一个引用消失，空间才会归还，所以保留策略与快照频率必须一起设计。另外，Set shared 会把多个参数之间重叠的共享 extent 一并算进去，所以同时传源和快照得到的数字比两者逐个相加更小。

还原点不是副本

快照与源在同一个文件系统的同一块设备上，控制器故障、坏盘，或者一次搞砸的 btrfs check，会一次带走数据以及它的每一份快照。它们只防一类事故——本不该发生的那次写入——并且防得极好：回滚是本地操作、瞬时完成、不需要网络。

真正的保护意味着独立副本：btrfs send 遍历快照并输出一条流，btrfs receive 把它落到另一个文件系统上，-p 只发送相对父快照的增量。把这条流送到另一台机器或另一个池。要分清的界限是：send 才是复制机制，快照只是被复制的对象。只读快照同时充当 btrfs send -p 的父快照，于是增量复制的粒度就由快照频率决定：打得越密，每次送出去的增量越小。

坏掉的样子

最经典的是删了却不释放：有人删掉一个 40 GB 的目录，df 纹丝不动，于是他继续删更多东西来“补偿”。对子卷和它的各个快照跑 btrfs filesystem du -s，找出 Exclusive 值恰好能解释这个缺口的那一个。如果快照是只读的，解决办法是删快照，而不是删更多文件。

第二种是文件系统写满，在 btrfs 上比 ext4 更糟。元数据需要自己的空间，而没有空闲空间的写时复制文件系统无法为一次写入分配新 extent，于是一个占用 100% 的文件系统会拒绝在别处本可成功的写入，甚至转为只读。留出余量——5% 不是多疑——给快照保留量设上限，并记住：给一个接近写满的文件系统打快照，等于同时承诺为它的分岔也找到空间。此时 btrfs filesystem usage 里的 unallocated 会先耗尽，然后才轮到 free；看到 unallocated 接近零就该动手，而不是等写入开始报错。

快速验证

确认快照是共享而不是复制，并找出是谁占着空间：

btrfs subvolume snapshot -r /data /snap/data-$(date +%F)
btrfs filesystem du -s /data /snap/data-2026-09-16
compsize /snap/data-2026-09-16
btrfs filesystem usage /data

du 对每条路径打印 Total、Exclusive、Set shared 三元组：新建快照的 Exclusive 至多是几 MiB 元数据，而 Set shared 应与源的 Total 相当。若 Exclusive 已经等于 Total，说明这不是快照而是完整拷贝。随后 btrfs filesystem usage 给出设备还能吸收多少分岔。要用 btrfs qgroup show -reF 的话得先 btrfs quota enable /data，没开配额时它不会报错，只是给不出数字。

来源

btrfs 子卷文档，子卷与快照语义，含只读快照，已核验 2026-09-16。
btrfs filesystem 文档，定义上文所用的 du Exclusive 与 Set shared 列，已核验 2026-09-16。
btrfs qgroup 文档，按 qgroup 统计 exclusive 与 referenced 字节，已核验 2026-09-16。
btrfs send 文档，把快照送出本机的复制流，已核验 2026-09-16。

LRU 缓存淘汰最久未用的条目

Fri, 12 Nov 2027 00:00:00 +0000

LRU 按最近使用顺序选择淘汰对象，而不是按历史热度、存放年龄或业务重要程度选择。有界缓存需要腾出空间时，精确的最近最少使用策略会移除最后一次有效访问发生得最早的条目。它利用的是时间局部性，既不保证命中有价值的数据，也不保证留下来的数据仍然新鲜。

沿访问顺序找出淘汰对象

假设缓存只能存三个条目，并按从旧到新的方向列出。依次加载 A、B、C 后，顺序为 A、B、C；再次读取 A，顺序变成 B、C、A；此时加载 D，就淘汰 B，留下 C、A、D。普通字典即使保留插入顺序，也不会因为某个条目被读取就自动调整它的位置。

实现必须明确哪些操作算作一次访问。常见精确方案把查找表与双向链表结合起来，以较低成本完成查找、移到最近端和从最旧端移除。维护顺序需要额外元数据，也让缓存命中变成状态更新；并发实现还必须协调这些更新，不能把读取缓存理解成永远没有写入开销。

精确顺序与采样近似不是同一契约

Redis 使用近似 LRU：抽取候选并维护较好的淘汰候选池，而不是为每个键保存完整的精确访问顺序。采样数量可以配置，更多采样用额外计算换取更接近精确 LRU 的结果。它不承诺下面小模型的逐个淘汰顺序，也不能由此推导所有淘汰操作都有固定耗时。

候选资格同样重要。Redis 的 allkeys-lru 可以淘汰任意键，volatile-lru 则只考虑带过期信息的键。设置了有效期，并不保证键在截止时间之前不会被淘汰；如果没有符合条件的带过期时间的键，volatile 策略在内存压力处理上会表现得像 noeviction。

容量约束不是新鲜度约束

限制三个条目，不等于限制三千字节。不同键、值和维护结构占用不同空间，按数量限制的缓存仍可能持有很大的对象。Python 的 lru_cache 会持有参数与返回值的引用，直到条目被淘汰或缓存被清空。选择容量单位时，应对应真正需要控制的资源，而不是只看条目数是否稳定。

最近访问也不能说明源数据有没有变化。频繁读取一个过时答案，反而可能让它一直留在缓存中。有效期、显式失效和版本化键分别处理新鲜度问题；淘汰规则既不是一致性协议，也不是备份策略，不能因为缓存命中就跳过业务对数据有效性的判断。

坏掉的样子

一次扫描大量只用一遍的条目，可能挤掉本来有用的工作集。容量为三时循环访问四个不同键，即使这些键都在被反复请求，也可能每次都未命中。LRU 不会因为过去访问次数很多就永久保留一个键。LFU、插入前的准入策略或调整容量可能适合某些负载，但不能仅凭“读多”就自动选出正确方案。

应在有代表性的时间段一起观察命中、未命中、淘汰、保留字节数以及未命中的代价。很高的命中率也可能掩盖少量特别昂贵的回源；单看淘汰数量，不知道被移除的数据是否有价值。修改策略前，先还原实际访问轨迹，再解释缓存为什么做出了这些选择。

缓存命中还必须允许安全复用。带副作用的函数，或每次调用都必须创建独立可变对象的函数，不适合直接做记忆化。Python 的 lru_cache 能保持多线程下内部结构一致，但同时发生的未命中仍可能让被包装函数执行多次。线程安全不等于抑制同一项工作被重复执行。

快速验证

将代码保存为 lru_check.py，用 Python 3.10 以上版本执行 python3 lru_check.py。实验已在 Python 3.14.4 上运行，只使用标准库：OrderedDict 展示精确访问顺序，真正的 functools 装饰器另行验证记忆化行为。不启动 Redis，不发送网络请求，也不写文件。

from collections import OrderedDict
from functools import lru_cache


def access(cache, key, capacity):
 assert capacity > 0
 hit = key in cache
 evicted = None
 if hit:
 cache.move_to_end(key)
 else:
 cache[key] = key.lower()
 if len(cache) > capacity:
 evicted, _ = cache.popitem(last=False)
 return hit, evicted, tuple(cache)


cache = OrderedDict()
observed = [access(cache, key, 3) for key in "ABCAD"]
assert observed == [
 (False, None, ("A",)),
 (False, None, ("A", "B")),
 (False, None, ("A", "B", "C")),
 (True, None, ("B", "C", "A")),
 (False, "B", ("C", "A", "D")),
]
print("ABCAD: touching A makes B the victim; final oldest -> newest:", tuple(cache))

for key in "XYZ":
 access(cache, key, 3)
assert tuple(cache) == ("X", "Y", "Z")
assert access(cache, "A", 3)[0] is False
print("a one-time XYZ scan displaces the old working set")

cache.clear()
hits = sum(access(cache, key, 3)[0] for key in "ABCD" * 3)
assert hits == 0
print("capacity 3, repeated ABCD: 0 hits in 12 accesses")

origin = {"A": 1, "B": 2, "C": 3}
loads = []


@lru_cache(maxsize=2)
def read(key):
 loads.append(key)
 return origin[key]


assert [read(key) for key in "ABACB"] == [1, 2, 1, 3, 2]
assert loads == ["A", "B", "C", "B"]
assert tuple(read.cache_info()) == (1, 4, 2, 2)
print("functools trace:", read.cache_info(), "origin reads:", loads)
origin["B"] = 20
assert read("B") == 2
read.cache_clear()
assert read("B") == 20
assert tuple(read.cache_info()) == (0, 1, 2, 1)
print("a recent cached B stays stale until explicit invalidation")

第一组断言检查每一步的顺序，而不只是最后的容量：读取 A 后，B 成为下一次淘汰对象。随后一次性访问 X、Y、Z，会挤走原工作集；再循环访问 A、B、C、D，容量为三的缓存十二次访问全部未命中。结果说明“这些键经常出现”并不足以保证 LRU 有收益，还取决于它们之间隔了多少其他访问。

装饰器包装的函数读取一份内存中的源数据。A、B、A、C、B 的轨迹得到一次命中、四次未命中和两个保留条目；记录的源读取列表明确指出哪些调用实际重新计算。把源数据 B 从二改为二十后，缓存仍返回二，直到执行 cache_clear 才读到二十；清空操作也会重置统计。

这些是确定性的正确性检查，不是延迟或内存基准。实验没有执行 Redis 采样淘汰、有效期处理、并发未命中、按字节限制容量或生产访问分布。先用轨迹理解规则，再针对真实缓存实现和真实工作负载验证，不能把小模型的结果直接当成生产命中率承诺。

来源

Python functools，LRU 记忆化、统计、对象引用、失效与并发调用边界，已核验 2026-09-08。
Python collections，OrderedDict 重排与端点移除，已核验 2026-09-08。
Redis 键淘汰，近似 LRU、采样与候选资格，已核验 2026-09-08。

LSM 树把前台写入成本转移到后续归并

Tue, 02 Nov 2027 00:00:00 +0000

LSM 树把一部分分散更新的成本转移到内存缓冲与后续归并。这是一种设计取舍，不是“所有磁盘操作从此完全顺序”的承诺，也不保证随机写一定胜过 B 树。真正需要回答的问题，是前台写入、后台压实、读取和保留版本，能否同时放进同一份资源预算。不能用一个没有提供数据生成器的精确耗时，替代对实际工作负载的解释。

缓冲改变工作的发生时机

RocksDB 通常把新写入放入内存表，并可同时写入预写日志。是否启用 WAL、是否同步日志，是另外的持久性选择；仅仅采用 LSM 布局，不保证每个已应答写入都能抵御断电。内存表填满后刷成不可变有序表，产生零层文件，应用则通过其他可用缓冲继续写入。日志追加、刷盘和压实也不是同一个动作。

采用分层压实时，零层文件的键范围可以重叠。更深的层通常各自组成一个有序段，但一个段可以按键范围拆为多个不重叠 SST 文件，不能理解为每层只有一个文件。查找先利用文件范围选择候选，压实则把重叠区间归并成替代文件。动态层大小配置还可能让某些中间层为空，因此不能把所有层永远填满的示意图当作运行事实。

读取仍然需要处理多个版本

同一个键的旧值可能存在于多个段中。读取要选择可见版本，而删除标记必须阻止更老的值重新出现。布隆过滤器可以排除肯定不含目标键的候选文件；返回可能存在后，仍需进一步检查。一次最终成功的查找，也能通过过滤器跳过不相关文件，再到真正包含答案的文件中读取。因此，“过滤器只帮助未命中，对命中毫无作用”并不准确。

压实通过重写数据，降低这种搜索和空间负担。分层策略与通用策略通常在写放大、读放大、空间放大之间作不同选择，但真实结果仍取决于负载、压缩、缓存和配置。统计时必须统一口径：SST 写入字节、WAL 字节、设备写入字节与应用逻辑字节不是同一种量。不写清分子分母的倍率，不能直接用来规划存储吞吐。

坏掉的样子

刷盘或压实跟不上时，不可变缓冲和零层文件可能积累，读取成本上升，引擎还可能减速或暂停前台写入。历史阻塞计数非零，不足以诊断今天的瓶颈。应同时查看最近的阻塞时间、待处理工作、文件数量、存储延迟与应用吞吐。提高阈值可能暂时推迟压力，却把更多工作留到后面，并扩大恢复时需要处理的积压。

删除不会立刻回收所有旧值。只要更低的段仍可能暴露被遮住的值，或保留快照需要相关历史，墓碑就不能随意消失。回收空间取决于压实覆盖了哪些历史，以及版本保留规则是否允许丢弃。若数据已经全部删除，活跃字节数为零，就不能再报告一个有限的“物理字节除以活跃字节”空间放大率；此时应直接报告残留字节与回收条件。

快速验证

把程序保存为 lsm_model.py，用 Python 3 执行。它明确只是标准库内存模型，展示三个刷出段和覆盖全部历史的压实。程序不会执行 RocksDB，不会创建真正 SST，不做磁盘输入输出，不模拟引擎调度，也不测延迟。打印的计数不能被重新包装成生产性能结果；示例的作用是把版本选择与墓碑删除条件具体化。

from pprint import pprint

# A semantic model: sorted in-memory runs, not RocksDB or a disk benchmark.
runs = [] # newest run first
writes = 0
sequence = 0

def flush(operations):
 global writes, sequence
 memtable = {}
 for key, value in operations:
 sequence += 1
 memtable[key] = (sequence, value)
 run = dict(sorted(memtable.items()))
 runs.insert(0, run)
 writes += len(run)

def get(key, tables):
 for run in tables:
 if key in run:
 return run[key][1] # None is a tombstone: stop searching.
 return None

flush([("a", "one"), ("b", "old")])
flush([("a", "two"), ("c", "three")])
flush([("b", None)])
assert [get(k, runs) for k in "abc"] == ["two", None, "three"]
assert writes == 5 and sequence == 5
# Dropping a tombstone from only the newest run resurrects old b.
unsafe = [{k: v for k, v in runs[0].items() if v[1] is not None}] + runs[1:]
assert get("b", unsafe) == "old"
# Merge ALL history, with no retained snapshots, before dropping tombstones.
latest = {}
for run in reversed(runs):
 latest.update(run)
merged = {k: v for k, v in sorted(latest.items()) if v[1] is not None}
writes += len(merged)
assert [get(k, [merged]) for k in "abc"] == ["two", None, "three"]
assert (len(merged), writes, sequence) == (2, 7, 5)
pprint({"live_keys": list(merged), "logical_operations": sequence,
 "table_records_written": writes, "record_write_ratio": writes / sequence,
 "unsafe_partial_merge_resurrects": get("b", unsafe)})

第一次刷出保存 a 和 b；第二次替换 a 并新增 c；第三次删除 b。跨所有段读取时得到新的 a、缺失的 b 和 c。反例刻意只从最新段移除墓碑，结果旧段中的 b 重新出现。这说明一条表面上没有业务值的删除记录，仍可能承担遮住历史版本的职责，不能因为它“看起来没用了”就局部删除。

安全的模型归并检查全部段，并假设没有保留快照，最后只保留两个值。这次合并再写两个表记录，因此五个逻辑操作总共写出七个记录，记录数倍率为一点四。这不是字节写放大：值大小差异、WAL、压缩、元数据，以及真实引擎的中间压实都没有被计算。模型还没有模拟快照读取、并发写入或崩溃恢复，不能把这些性质附加到结果上。

对真实引擎，应在隔离数据库中重现代表性的插入、更新、删除和读取，记录选项与硬件，再检查实际计数器。SQLite 的顺序与乱序更新耗时，不足以证明 RocksDB 的行为；后台吞吐缺口也不能直接推出多久填满磁盘，除非另有关于保留、回收、限流和可用容量的模型。先明确每个观测量表示什么，再判断究竟需要更多带宽、更少版本、不同压实策略，还是更合适的写入节奏。

来源

RocksDB 概览，内存表、可选 WAL、持久性与压实，已核验 2026-10-15。
RocksDB 分层压实，有序段、文件、层大小与积压，已核验 2026-10-15。
RocksDB 布隆过滤器，候选过滤与假阳性，已核验 2026-10-15。
RocksDB 快照，压实时保留版本的要求，已核验 2026-10-15。

稀疏文件把逻辑长度与分配块分开

Mon, 11 Oct 2027 00:00:00 +0000

稀疏普通文件可以具有很大的逻辑长度，却只为其中部分地址范围分配存储。读取长度范围内的空洞会得到零字节，因此文件长度、字节内容和文件系统分配，是三项不同测量。为虚拟磁盘预算容量、复制备份，或者判断零区域是否已为将来写入保留空间时，都需要理解这种关系，不能用其中一个数字替代另外两个。

坏掉的样子

seek 越过文件结尾，只改变描述符偏移，不改变文件长度。后续写入或显式扩展，才可能创建中间读为零的范围。只调用 seek，就声称已经创建大型稀疏文件，是错误的；同样，逻辑大小很大，也不表示文件系统已经预留足够块，允许以后填满它。偏移位置、逻辑范围与实际容量承诺必须分开。

如果复制读取每个字节并普通写出，就可能把空洞变成分配了块的零区域。最终校验值完全相同，分配空间却大得多。传输或恢复流程若只依据源文件当前分配量做预算，即使正确保留逻辑内容，也可能耗尽目标容量。因此成功复制字节与保持稀疏表示，是需要分别验证的目标。

打洞是有意改变数据的操作。配合 KEEP_SIZE 对已分配范围打洞，会保持长度，却让对应字节读为零，并不是可以随手清理任意文件区域的无害命令。预分配解决另一类问题：它保留文件系统分配，即使未写入的已分配范围也可能读为零。内容都是零，不能证明这两种表示具有相同空间行为。

快速验证

把脚本保存为 sparse.py，在一次性 Linux 系统中使用 Python 3.11 或更新版本运行 python3 sparse.py，临时目录需位于 ext4。实测使用 Linux 6.12.76 和 Python 3.11.2。样本创建三个临时文件，使用约三十二 MiB 完整分配数据，以及少量稀疏分配：

from pathlib import Path
from tempfile import TemporaryDirectory
import ctypes,hashlib,os

size=16*1024*1024;first=4*1024*1024;second=12*1024*1024
libc=ctypes.CDLL(None,use_errno=True);libc.fallocate.argtypes=[ctypes.c_int,ctypes.c_int,ctypes.c_longlong,ctypes.c_longlong];libc.fallocate.restype=ctypes.c_int
def digest(path):
 with path.open('rb') as handle:return hashlib.file_digest(handle,'sha256').hexdigest()
with TemporaryDirectory(prefix='xbcatm-sparse-') as directory:
 root=Path(directory);path=root/'sparse';fd=os.open(path,os.O_RDWR|os.O_CREAT|os.O_EXCL,0o600)
 try:
 os.lseek(fd,size,os.SEEK_SET);assert os.fstat(fd).st_size==0
 os.ftruncate(fd,size);assert os.fstat(fd).st_size==size and os.fstat(fd).st_blocks==0
 assert os.pread(fd,16,0)==b'\0'*16
 os.pwrite(fd,b'A',first);os.pwrite(fd,b'B',second);os.fsync(fd)
 allocated=os.fstat(fd).st_blocks*512;assert allocated<size
 data_start=os.lseek(fd,0,os.SEEK_DATA);hole_start=os.lseek(fd,data_start,os.SEEK_HOLE)
 assert data_start==first and first<hole_start<=second
 print('seek alone leaves size zero; truncate creates zero-reading holes; sparse size',size,'allocated',allocated)
 print('first SEEK_DATA',data_start,'following SEEK_HOLE',hole_start)
 dense=root/'dense'
 with path.open('rb') as source,dense.open('wb') as target:
 while chunk:=source.read(65536):target.write(chunk)
 target.flush();os.fsync(target.fileno())
 assert digest(path)==digest(dense)
 assert dense.stat().st_blocks*512>=size
 print('explicitly writing all copied bytes preserves content but allocates the zero-filled ranges')
 result=libc.fallocate(fd,0x01|0x02,first,4096) # KEEP_SIZE | PUNCH_HOLE
 assert result==0,os.strerror(ctypes.get_errno())
 os.fsync(fd)
 assert os.fstat(fd).st_size==size and os.pread(fd,1,first)==b'\0'
 assert os.pread(fd,1,second)==b'B' and os.fstat(fd).st_blocks*512<allocated
 print('punching the aligned data range releases its blocks and makes it read zero without changing file length')
 reserved=root/'reserved'
 with reserved.open('w+b') as handle:
 os.posix_fallocate(handle.fileno(),0,size);os.fsync(handle.fileno())
 info=os.fstat(handle.fileno());assert info.st_size==size and info.st_blocks*512>=size
 assert handle.read(16)==b'\0'*16
 print('preallocation reserves blocks even while the newly allocated range reads as zeros')
 finally:os.close(fd)

样本先在空文件中 seek 到十六 MiB，确认大小仍为零。随后 truncate 到这个长度，在本次 ext4 环境中得到逻辑十六 MiB、尚无已分配数据块的文件，读取开头为零。这个对照直接区分移动偏移与扩展文件，而不是依据 seek 返回了一个大数字，就推测文件内容范围已经改变。

在四 MiB 和十二 MiB 分别写入一个字节后，两个小区域获得分配。同步后，记录的逻辑长度为一千六百七十七万七千二百一十六字节，报告分配量为八千一百九十二字节。Linux 的 st_blocks 按五百一十二字节单位换算，不能误当成文件系统较大的块大小，否则计算出的占用会出现偏差。

记录中首次 SEEK_DATA 为四百一十九万四千三百零四，后续 SEEK_HOLE 为四百一十九万八千四百。这些值描述第一个写入字节附近的 ext4 区域，不是只标记那个非零字节。数据区间里也可以含零，因此区间报告不能替代查找非零内容，两种问题应使用各自合适的观察方法。

脚本通过普通写入把全部逻辑字节复制到第二个文件，摘要与稀疏源一致，分配量却覆盖整个逻辑长度。这个受控密实复制展示扩张风险，没有声称每种现代复制工具或文件系统都会用相同方式实体化空洞。评估真实迁移时，需要测试实际工具、选项和目标端，而不是泛化一次普通复制结果。

接着对齐打洞移除第一个已分配数据区域，原来的 A 变成零，远处 B 保留，文件长度不变，分配块减少。第三个文件通过预分配保留十六 MiB 空间，开头内容仍读为零。两项结果分别说明打洞会改变有效字节，以及零内容本身无法区分空洞和已经预留的分配。

为需要的表示做预算并保留它

应在真实归档、传输和恢复之后，同时检查逻辑大小与分配块。感知稀疏的选项可能保留空洞，压缩、reflink 和文件系统专用复制又可能建立其他存储关系。文件系统共享或压缩区间时，单文件报告的分配量，也不应直接解释成它独占的物理设备用量，需要结合具体存储机制理解。

需要为未来分配保留空间时，应使用目标文件系统文档规定的预分配契约。仅被 truncate 扩大的虚拟镜像，之后仍可能增加实际占用，并在共享池满时失败。容量规划要考虑预期填充规模和竞争分配，不能只看创建时一个很小、看起来很省空间的数字，就认为后续写入预算已经落实。

SEEK_DATA 与 SEEK_HOLE 提供的是文件系统报告的区间信息，实现允许保守报告空洞，例如把更大范围视为数据。依赖精确偏移前，应验证支持和行为。打洞或复制区间时，首先保留应用预期字节；只有结果数据与分配关系符合操作目的，节省空间才有实际价值，不能为了较小数字破坏内容。

来源

lseek(2)，定位偏移、SEEK_DATA/SEEK_HOLE 与文件系统报告边界，已核验 2026-09-12。
truncate(2)，扩展逻辑长度并使新增区域读为零，已核验 2026-09-12。
fallocate(2)，预分配与保持逻辑大小的打洞，已核验 2026-09-12。
Linux 6.12 fallocate UAPI，样本使用的 KEEP_SIZE 与 PUNCH_HOLE 标志，已核验 2026-09-12。

PVC 为 Pod 提供容器之外的持久存储

Fri, 13 Aug 2027 00:00:00 +0000

容器本性易失，所以要用 PersistentVolumeClaim 把真实存储钉到它身上，即使 Pod 被重建也不丢数据。这个拆分是刻意的：PersistentVolume 声明已经存在的容量，PersistentVolumeClaim 请求需要的容量，由控制器把两者配上。有了 StorageClass，声明还能通过 provisioner 自己创建卷，于是没人需要预先造好存储。

真正会咬人的是：声明与卷各自有独立的生命周期，由各自的规则管着。finalizer 决定声明什么时候才允许消失，回收策略决定卷之后会怎样。删除顺序搞错，就会得到一个卡在 Terminating 的声明；策略搞错，可能删掉本想保留的数据，也可能留下一份没人在用却仍在计费的存储。

声明、卷与绑定

绑定是一次「全部满足」而不是「最接近」。一块卷只有在容量不小于请求、访问模式包含所请求的模式、storageClassName 匹配，并且没有被别的声明占用时，才是候选。除了这几项，volumeMode（Filesystem 与 Block）也必须一致；而已经释放却还没清理的卷并不会变回可用的备件，它的 claimRef 仍指向上一个声明，所以新的声明根本看不到它。什么都不满足的声明会停在 Pending，并带一条指明究竟哪一项没满足的事件，这比一句笼统的失败有用得多；常见原因是要的访问模式该类交付不了，以及类名根本不存在。

accessModes 没有默认值，必须选一个，而多数单节点块存储 provisioner 实际能交付的就是 ReadWriteOnce。它同时是单节点的，所以副本分布在不同节点上的 StatefulSet 无法共用一份声明。类支持动态供应时，volumeBindingMode 决定时机：Immediate 在声明一出现就创建卷，可能把受拓扑限制的卷放到没有节点能用的可用区；WaitForFirstConsumer 则让声明一直 Pending，直到出现消费 Pod，再结合调度约束协调绑定或供应，然后才能完成放置；它不是先完成调度再随意创建卷。

删除顺序与 finalizer

顺序是 Pod、声明、卷，保护机制由 finalizer 实现。在 Pod 仍挂载着声明时删除声明，什么都不会被删掉：声明拿到删除时间戳、翻成 Terminating，然后停在那里，因为 kubernetes.io/pvc-protection 仍在它的 finalizer 列表里。只有再没有任何 Pod 引用这份声明时，控制器才会摘掉那个 finalizer，所以那个「永远 Terminating」的 PVC 可能仍被 Pod 引用，但控制器延迟和其他 finalizer 也需要调查，不能只看状态就排除控制面问题。

反方向也有同样的保护。PersistentVolume 带着 kubernetes.io/pv-protection，所以删除一块已绑定到声明的卷会被推迟到它不再被绑定为止。这个顺序只是延迟误删除，并不代表可以撤销已经设置的 deletionTimestamp，也解释了为什么只要声明还在，卷看起来就会无视删除命令。

回收策略：Delete 还是 Retain

声明最终消失后，卷被释放，回收策略接手。Delete 会删掉 PV 对象以及外部基础设施上的存储资产。Retain 保留 PV 对象、把它标成 Released，并且刻意不让它被新的声明使用，因为上一个占用者的数据还在上面——回收于是变成一串手工动作：确认归属与备份，再按存储提供方流程有意回收、复用或删除资产，而不是把删除写成唯一结局。

动态供应的卷会继承其 StorageClass 的策略，而后者默认是 Delete。这个默认是否适合数据库，取决于保留和恢复要求，而且它容易被忽略：PVC 与 Pod 清单里都没有一个字提到策略，决定是几个月前在一个集群级对象里做出的，审阅工作负载的人从来看不到。所以在评审一份有状态工作负载时，回收策略应当和容量、访问模式放在一起看。

坏掉的样子

最经典的是删不掉的声明。有人删了 PVC，看到 Terminating，然后开始等——而某个 Pod 仍然挂着它，通常是没缩容到零的 StatefulSet，或者卡在不可达节点上的 Pod。没有报错，没有超时，而这份 PVC 一直占着背后的存储。正确做法是找到那个 Pod，而不是手工删 finalizer；绕过保护可能让仍被工作负载使用的存储过早进入删除流程，并非每个提供程序都会立即执行相同的分离动作。

第二种是 Retain 留下的孤儿。声明没了，Pod 没了，命名空间可能也没了，一块 Released 的 PV 和它的存储资产仍等待有意回收。保留可能本来就符合要求；如果没有资产盘点告警，就容易被遗漏，任何工作负载的清单里也看不到它。反向的错误同样安静：某个类的默认 Delete 策略从未被覆盖，等到有人想找回数据时才发现回收早已把它删掉了。

快速验证

同时看绑定的两侧，以及是谁占着这份声明：

kubectl get pvc -A -o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,STATUS:.status.phase,VOLUME:.spec.volumeName,CLASS:.spec.storageClassName
kubectl get pv -o custom-columns=NAME:.metadata.name,STATUS:.status.phase,POLICY:.spec.persistentVolumeReclaimPolicy,CLAIM:.spec.claimRef.name
kubectl get pvc data -o jsonpath='{.metadata.finalizers}{"\n"}'
kubectl get pods -A -o json | jq -r '.items[] | select(.spec.volumes[]?.persistentVolumeClaim.claimName=="data") | "\(.metadata.namespace)/\(.metadata.name)"'

这些保留的诊断本轮没有执行。保护标记说明清理待完成，不证明控制器健康，也不证明一定还有 Pod。第四条查找所有命名空间内名为 data 的声明，因此必须先核对目标命名空间，再确认某个 Pod 是否是消费者。Released 加 Retain 需要归属与恢复决策，不代表应自动删除；旧 claimRef 也可能仍然存在。

来源

Persistent Volumes，绑定、访问模式、回收策略、Released 状态与 pvc/pv 保护 finalizer，已核验 2026-10-15。
Storage Classes，动态供应、reclaimPolicy 与 volumeBindingMode，已核验 2026-10-15。

NFS 把远程目录通过网络共享出去

Wed, 23 Jun 2027 00:00:00 +0000

一个 NFS 导出，是服务器上的一个目录加上一份允许访问它的客户端名单；而描述它的那个文件，并不是真正对外服务的东西。/etc/exports 由 exportfs 读取，exportfs 把主导出表写进 /var/lib/nfs/etab，客户端发来 MOUNT 请求时，是 rpc.mountd 去查这张表。三个文件：一个由人编辑，另外两个才决定实际发生什么。

这层间接就是最常见的 NFS 事故的来源：导出列表看着没问题，客户端却被拒，因为文件变了而表没变。剩下的配置归结为两个更难的问题——服务器认为一个请求带着什么身份，以及一个回答“已写入”的回复能不能挺过服务器崩溃。

文件与表

/etc/exports 的一行是 <目录> <客户端>[(<选项>)] ...，所以 /srv/data 10.0.0.0/24(rw,sync,no_subtree_check,root_squash) 把某个目录以四个选项导出给一个网段，同一行后面还能再接一组客户端、带自己的一套选项。客户端可以写成主机名、通配符、CIDR 网段或 netgroup；# 之后到行尾是注释，行尾反斜杠表示续行。文件里的内容在 exportfs -ra 依据它重建表之前一律不生效，而 exportfs -v 打印的是真正被加载的那张表，所以它既能用来核对文件里的每一条，也能用来发现表里多出来的东西。

showmount -e 从客户端一侧展示同一张表：它问的是 mount 守护进程而不是文件，所以它回答的是“服务器认为自己导出了什么”，而不是“我刚才写了什么”。fixture 精确复现了这个陷阱：把 /srv/newshare 追加进导出文件却没有重新导出之后，文件里有四条，表里只有三条，客户端请求这个新共享得到的是 NOENT。

选项真正决定了什么

ro 与 rw 决定写方向，而且只读是默认值：不写 rw，任何会改动文件系统的请求都会被拒绝——这一点常被忽略，默认是只读，要让人写入必须显式写上 rw。sync 与 async 决定服务器什么时候可以回答——sync 是先提交到稳定存储再回复，async 则可能先回复、后提交，文档明确说这会让一次崩溃丢掉已经应答过的写入。async 是 nfs-utils 1.0.0 之前的默认值；从那时起默认就是 sync。

squash 系列选项是身份策略。root_squash 把远端的 uid 0 映射成匿名 uid，绝大多数场合都该用它；no_root_squash 让客户端的 root 在服务器上就是 root，只有在你本来就信任那台主机时才说得过去；all_squash 配合 anonuid/anongid 把所有客户端 id 都映射成同一个匿名身份，这才是公开共享该有的形状。subtree_check 与 no_subtree_check 是可靠性开关，不是安全开关：开启子树检查时服务器要确认被请求的文件仍在导出子树内，于是文件在客户端打开期间被重命名就可能访问失败；自 nfs-utils 1.1.0 起默认是 no_subtree_check。

挂载，以及 id 映射陷阱

mount -t nfs -o vers=4.2 server:/srv/data /mnt/data 把导出挂进来；用 NFSv4 时你可以只导出一次 /（配 fsid=0），再按路径挂载子树。优先用 hard（也是默认值），因为 soft 挂载在 retrans 次重传之后就放弃并向应用返回 EIO，man page 明确警告这可能导致静默的数据损坏；代价是服务器不可达时，一次 ls 会变成卡在 D 状态的进程。intr 已经帮不上忙：自内核 2.6.25 起它就被忽略了。

权限由数字 uid/gid 对照服务器上的账号决定，而不是按名字，所以一个在服务器上没有对应账号的客户端 id 会落到匿名 uid 上。两边都跑 id、再在挂载点上跑 ls -ln，就是那个检查：你自己拥有的文件显示成 65534，说明是映射错了，而不是权限位错了。

坏掉的样子

最经典的是导出表过期，而且两个方向都会出问题。加进文件却从未导出的共享是不可见的；从文件里删掉却从未重新导出的共享仍在对外服务，对象正是你以为已经锁掉的那些客户端。两种情况都靠 exportfs -ra 修好，也都能通过把 /etc/exports 与 exportfs -v 对比看出来。

第二种是客户端卡死。对不可达服务器的 hard 挂载会在内核里无限阻塞，于是所有碰这个挂载点的进程都杀不掉，机器上越积越多 D 状态进程；fixture 里那条 showmount -e 127.0.0.1 花了 35 秒才失败，正是同一个 RPC 超时，让一个坏掉的 NFS 挂载看起来像 ls 卡住，而不像报错。那个诱人的修法 soft，是用静默的写入损坏去换掉这次卡死。

快速验证

把已加载的表与文件对照，然后检查 id：

exportfs -v
showmount -e localhost
exportfs -ra && exportfs -v
mount | grep 'type nfs'
id; ls -ln /mnt/data | head

exportfs -v 必须与 /etc/exports 里的目录和选项集合完全一致（顺序无所谓，集合不能差）；少了什么就说明表是过期的，此时文件看着没错，客户端拿到的却是 NOENT。showmount -e 从远端调用时应当打印同一组目录。在客户端一侧，id 与 ls -ln 对数字属主的判断必须一致——显示为 65534 或 nobody，说明服务器上没有对应账号。

来源

exports(5)，导出语法、squash 选项、sync/async 与 subtree_check 默认值，已核验 2026-09-16。
exportfs(8)，/var/lib/nfs/etab 中的主导出表以及 exportfs 如何维护它，已核验 2026-09-16。
nfs(5)，挂载选项，含 hard/soft、timeo 以及 intr 的失效，已核验 2026-09-16。
showmount(8)，从客户端查询服务器的导出列表，已核验 2026-09-16。

RDB 与 AOF：两种保住 Redis 的方式

Tue, 15 Jun 2027 00:00:00 +0000

RDB 与 AOF 保存的是 Redis 状态的不同表示。选择之前应回答两个问题：允许丢失多少近期数据，以及可以接受多长恢复时间？单独一个持久化开关无法回答这些问题。真正需要的是可恢复的文件、明确的写入确认策略，以及验证过具体数据值的恢复流程，而不只是能够启动的进程。

快照记录一个时点，不保证固定间隔

RDB 是紧凑的时点数据集。BGSAVE 派生子进程，先写临时文件，完成后再替换旧快照；父进程继续处理请求，但派生进程、写时复制增加的内存以及磁盘工作仍有成本。SAVE 则同步保存并阻塞其他客户端，本文只把它用于很小的隔离测试数据，不应照搬到繁忙服务上。

例如 save 60 1000 同时要求经过指定时间并达到修改次数条件，不是“无论有多少修改，每六十秒都必定生成一份快照”，也不保证保存能按时成功完成。实际恢复暴露窗口取决于最近一份可用快照的状态有多旧；漏掉或失败的保存会扩大这个窗口。因此，要检查成功保存的记录与结果，不能只看配置中的时间数字。

AOF 改变恢复数据的表示

AOF 记录数据变更，并按 appendfsync 策略同步。everysec 通常暴露大约最近一秒的写入，no 把刷盘时机交给操作系统；always 在有效配置允许的情况下先同步再回复，代价是额外的同步开销。这些策略不保护整块存储设备丢失，也不能保证故障切换时被提升的副本包含每一条已经在原节点落盘的写入。

现代 AOF 是 manifest、基础文件和增量文件组成的集合，基础文件可以使用 RDB 格式。因此，“AOF 启动必定从头回放庞大的文本历史”不准确；重写还会去掉重建当前状态不再需要的历史操作。文件大小、启动耗时、重写开销和请求延迟，应结合实际数据集测量，不能仅凭 RDB 或 AOF 的名称排序。

两者同时启用，不等于自动合并

在没有额外启动覆盖的通常配置下，启用了 AOF 的 Redis 会选择 AOF 恢复，而不是先独立加载 dump.rdb，再把另一份日志叠加上去。AOF 内部的 RDB 格式基础文件属于其自身文件集合。另行保留的 RDB 仍可用于备份和明确选择的恢复操作，但不会自动补齐缺损的 AOF 文件。

已有的 RDB 部署也不能仅修改 appendonly 然后直接重启。应遵循官方的在线转换流程，等待初始 AOF 成功生成，并把配置持久化，之后再考虑重启。下面的两个测试分别从空目录开始，目的在于比较恢复语义，绝不是迁移已有数据库的操作清单，更不应替换成生产目录运行。

坏掉的样子

BGSAVE 请求成功只代表请求被接受，不代表快照已经成功完成。存储写入失败、无法创建子进程或磁盘空间不足，都可能让实际可用恢复点停留在很久之前。需要结合 INFO persistence、错误日志和资源余量判断；即使 Redis 仍能回复请求，后台持久化也可能已经失败或显著恶化尾延迟。

如果唯一文件副本与服务位于同一台机器、共享同一个故障范围，那么两种格式都还不能算独立备份。应在机器之外保留一致副本，并实际恢复验证。AOF 会保存应用误删的结果，快照也可能已包含同一个错误。历史留存和应用层数据核验，不能被“进程已经可以接受连接”代替。

快速验证

准备 POSIX 环境、C 编译器、make、curl、tar，以及 Python 3.10 以上版本。实验已在 macOS、Redis 8.10.1、redis-py 8.1.0、Python 3.14.4 上执行。以下步骤只用 libc 构建 Redis 核心，将客户端装进临时虚拟环境，不改变系统级安装。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行 Python 代码。每组测试都有独立目录和 Unix socket，不监听 TCP，不安排自动快照。两组都主动保存一份小快照，只有第二组启用 AOF，并使用 always、保持重写期间同步。SIGKILL 只作用于代码创建的子进程；数据文件保留到重新启动并核验完成，随后清理临时目录。

from contextlib import contextmanager
import os
from pathlib import Path
import signal
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance(directory, aof):
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--dir", directory, "--dbfilename", "dump.rdb", "--save", "",
 "--appendonly", "yes" if aof else "no", "--appendfsync", "always",
 "--appenddirname", "appendonlydir", "--appendfilename", "appendonly.aof",
 "--aof-use-rdb-preamble", "yes", "--no-appendfsync-on-rewrite", "no",
 "--auto-aof-rewrite-percentage", "0",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client, process
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode in (0, -signal.SIGKILL), errors.decode()


def crash(process):
 assert process.poll() is None
 process.kill()
 assert process.wait(timeout=5) == -signal.SIGKILL


for aof in (False, True):
 with TemporaryDirectory(prefix="redis-restore-", dir="/tmp") as directory:
 with instance(directory, aof) as (client, process):
 assert client.set("version", "snapshot")
 assert client.incr("counter") == 1
 assert client.save()
 snapshot = (Path(directory) / "dump.rdb").read_bytes()
 assert snapshot.startswith(b"REDIS")
 assert client.set("version", "after-snapshot")
 assert client.set("later", "present")
 assert client.incr("counter") == 2
 if aof:
 assert client.info("persistence")["aof_last_write_status"] == "ok"
 crash(process)

 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 with instance(directory, aof) as (client, process):
 expected = ([b"after-snapshot", b"present", b"2"] if aof
 else [b"snapshot", None, b"1"])
 assert client.mget("version", "later", "counter") == expected
 assert client.dbsize() == (3 if aof else 2)
 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 print("RDB + AOF" if aof else "RDB only", expected)
print("an unchanged standalone RDB does not override enabled AOF recovery")

RDB-only 恢复出的 version 是 snapshot，later 键不存在，计数器是一；启用 AOF 的那组得到 after-snapshot、后来写入的 later 键，以及计数器二。两组的独立 RDB 文件字节在进程被杀和检查重启期间都保持不变，说明第二组不是因为偷偷又保存了一份新快照才恢复更新的数据。

计数器刻意没有先用 SET 初始化：快照里已有一，如果错误地把两次递增再回放到它上面，结果就会变成三，而不是正确的二。这让实验能够检查状态语义，而不只是确认进程启动或键数量相同。

SIGKILL 跳过正常关闭，但并没有让操作系统崩溃，也没有清空文件系统缓存。因此，该实验建立的是快照恢复边界和通常的 AOF 启动选择，并未验证断电、备份传输完整性、副本故障切换或生产数据量下的恢复时间。作出更强承诺之前，应为这些情形分别安排验收。

来源

Redis 持久化，快照、AOF 启动选择、在线转换与备份，已核验 2026-09-08。
Redis SAVE，同步快照行为与阻塞成本，已核验 2026-09-08。
Redis BGSAVE，后台保存及请求被接受的含义，已核验 2026-09-08。
Redis INFO，持久化进度与结果字段，已核验 2026-09-08。
Redis 8.10.1 配置，快照触发条件与 AOF 策略，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与选择分配器，已核验 2026-09-08。

UNLOGGED 表减少数据日志，也放弃内容的崩溃恢复

Mon, 24 May 2027 00:00:00 +0000

PostgreSQL 的 UNLOGGED 表保留正常 SQL 事务行为，但放弃其内容的崩溃恢复能力。它适合能够重复生成的暂存数据，不适合把唯一副本托付给一次提交。判断边界是服务器是否经历了非正常关闭后的恢复，不能简单地把“重启”两个字等同于数据丢失，也不能因为一次正常重启后行还在，就认为它具备持久性保证。

哪些内容跳过 WAL

非日志表的数据变化及其索引变化不写入预写日志。系统目录的变化仍可能产生 WAL，同一个事务还可能修改普通表，所以不能把整个工作负载描述为“完全没有 WAL”。表的数据页仍然占据存储空间，仍要经过缓冲区管理和后续写回；UNLOGGED 并不是内存表，也不是不需要磁盘的缓存。写入收益来自减少特定日志工作，实际改善幅度需要测量，不能承诺固定倍数。

服务器正常运行时，事务、快照、约束和回滚仍然生效。语句被拒绝或应用断开连接，并不意味着此前提交的全部行都会消失。但是后端进程异常退出可能导致服务器重启其他进程并进入恢复，因此也不能声称“应用事件绝不影响非日志表”。排查时应查看 PostgreSQL 日志和恢复过程，而不是仅凭事故最初发生在哪一层就推断数据状态。

重启与复制的边界

干净关闭后，非日志表内容会保留到下次启动。pg_ctl 的 fast 模式会回滚正在执行的事务并正常关闭，immediate 模式则直接中止进程，不完成干净关闭。后者需要崩溃恢复，恢复期间非日志关系会被重置：表定义仍在，但此前提交的行不再存在。主机维护若完成了干净关闭，并不会仅因为“重启”就清空这类表；反过来，不能把正常关闭的测试当成抗崩溃证明。

物理备库不会收到非日志表的数据内容。备库仍处于恢复模式时，读取这类关系会报错，而不是成功返回零行。提升为主库后可以读取它，但没有已经复制过来的行可以恢复。因此故障切换流程必须先重建或重新填充，再允许依赖这些数据的消费者进入服务。主备拥有同一个表定义，只说明目录信息存在，并不代表表中业务数据已经复制。

普通日志表不能用外键引用非日志表。PostgreSQL 会拒绝这样的建表语句，因为持久化的子表引用不能安全依赖可能在恢复中消失的父表行。下面的实验直接检查这一限制，不会把它描述成“外键还在、父表行没了、数据库默默允许不一致”。设计暂存区时，要把关系约束放到符合持久性边界的位置，而不是事后修补孤立记录。

坏掉的样子

一个常见事故是导入程序把文件装入非日志暂存表后就确认成功，并删除唯一的原始文件。随后服务器崩溃，暂存行消失，而输入已无处重取，这就变成不可恢复的数据丢失。原始输入应该至少保留到持久化目标提交成功，重建流程也必须知道需要哪一个输入版本。去重记录和导入检查点要属于持久化契约，不能和暂存内容一起丢掉。

另一个问题出现在报表服务改读备库，或刚完成提升就立即对外服务。只检测行数为零会漏掉恢复模式下的读取错误；无限重试也无法生成不存在的数据。应明确标记“正在重建”，在重建完成且结果验证通过前控制请求准入。演练要测量重建耗时、上游是否可用、记录数及内容是否符合预期；只建回一张空表不算恢复，能运行的脚本也不等于已经证明恢复时间满足要求。

快速验证

把 Bash 代码保存为 unlogged.sh。它要求以非 root 用户执行 PostgreSQL 18 的命令行工具。下面的容器命令提供工具，不发布网络端口，也不挂载宿主机数据；两个实验数据库都位于容器内的新临时目录。

docker run --rm --network none --user postgres --entrypoint bash -i \
 postgres:18-alpine < unlogged.sh

#!/usr/bin/env bash
set -euo pipefail
pg_lab=$(mktemp -d /tmp/unlogged-lab.XXXXXX)
cleanup() {
 for cluster in standby primary; do
 if [ -f "$pg_lab/$cluster/postmaster.pid" ]; then
 pg_ctl -D "$pg_lab/$cluster" -m immediate -w stop >/dev/null
 fi
 done
 rm -rf -- "$pg_lab"
}
trap cleanup EXIT
primary() { psql -X -h "$pg_lab" -p 55432 -d postgres -v ON_ERROR_STOP=1 "$@"; }
standby() { psql -X -h "$pg_lab" -p 55433 -d postgres -v ON_ERROR_STOP=1 "$@"; }
start_primary() {
 pg_ctl -D "$pg_lab/primary" -l "$pg_lab/primary.log" \
 -o "-k $pg_lab -p 55432 -c listen_addresses=''" -w start >/dev/null
}
initdb -D "$pg_lab/primary" --no-locale --encoding=UTF8 --auth=trust >/dev/null
start_primary
primary <<'SQL'
CREATE TABLE durable (id integer PRIMARY KEY);
CREATE UNLOGGED TABLE scratch (id integer PRIMARY KEY);
INSERT INTO durable VALUES (1);
INSERT INTO scratch VALUES (1);
BEGIN;
INSERT INTO scratch VALUES (2);
ROLLBACK;
DO $$
BEGIN
 EXECUTE 'CREATE TABLE durable_ref (id integer REFERENCES scratch(id))';
 RAISE EXCEPTION 'a logged table unexpectedly referenced an unlogged table';
EXCEPTION WHEN invalid_table_definition THEN
 RAISE NOTICE 'logged-to-unlogged foreign key rejected';
END $$;
SQL
counts='SELECT (SELECT count(*) FROM durable), (SELECT count(*) FROM scratch)'
test "$(primary -Atc "$counts")" = '1|1'
pg_ctl -D "$pg_lab/primary" -m fast -w stop >/dev/null
start_primary
test "$(primary -Atc "$counts")" = '1|1'
printf 'clean restart: 1|1\n'
pg_basebackup -h "$pg_lab" -p 55432 -D "$pg_lab/standby" -R -X stream -c fast
pg_ctl -D "$pg_lab/standby" -l "$pg_lab/standby.log" \
 -o "-k $pg_lab -p 55433 -c listen_addresses=''" -w start >/dev/null
test "$(standby -Atc 'SELECT pg_is_in_recovery()')" = t
test "$(standby -Atc 'SELECT count(*) FROM durable')" = 1
if standby -Atc 'SELECT count(*) FROM scratch' 2>"$pg_lab/read-error"; then
 echo 'unlogged read unexpectedly succeeded on standby' >&2
 exit 1
fi
grep -F 'cannot access temporary or unlogged relations during recovery' "$pg_lab/read-error"
pg_ctl -D "$pg_lab/standby" -w promote >/dev/null
test "$(standby -Atc "$counts")" = '1|0'
printf 'promoted standby: 1|0\n'
pg_ctl -D "$pg_lab/primary" -m immediate -w stop >/dev/null
start_primary
test "$(primary -Atc "$counts")" = '1|0'
printf 'crash recovery: 1|0\n'
primary -Atc 'SHOW server_version'
echo 'PASS: rollback, foreign key restriction, clean restart, standby, promotion, crash'

主库与备库使用同一个临时目录中的不同 Unix 套接字端口，退出时的 trap 只关闭这两个实验集群并移除其文件。实验故意对临时主库执行 immediate 关闭，不能把这一步改成已有数据库目录。PostgreSQL 18.6 上，回滚和正常重启后的计数都是 1|1；仍处于恢复模式的备库拒绝读取 scratch。备库提升和主库崩溃恢复后分别得到 1|0，表明持久化行还在而暂存内容不在。错误文本断言使用集群的 C locale，避免本地化消息造成误判。

这些结果验证生命周期和约束语义，不代表已经测出吞吐量改善，也不证明所有文件系统在真实掉电后的表现。性能评估还应计入输入保留和重建成本。持久化目标必须保留正常 WAL 与持久性配置；如果同时关闭这些保护，就改变了对照条件，无法再用本实验说明普通表与非日志表的区别。

来源

PostgreSQL CREATE TABLE，非日志表内容及其关联索引，已核验 2026-09-10。
PostgreSQL WAL 介绍，恢复与持久性的作用，已核验 2026-09-10。
PostgreSQL pg_ctl，干净关闭与立即关闭模式，已核验 2026-09-10。

桶版本化与生命周期管理成本

Sat, 08 May 2027 00:00:00 +0000

S3 版本化在同一个键下保留多个版本，只要所需版本仍在，就能恢复许多误覆盖和普通删除。它并不防止所有删除，也不会独立构成备份。真正能否恢复应用，取决于保留策略、访问权限、加密密钥是否仍然可用，以及恢复程序是否经过验证。版本存在与业务恢复成功之间，还有需要明确检查的步骤。

分清版本化状态

在启用版本化的桶中，PUT 产生新版本 ID，同时保留之前的数据版本。每个版本存储完整对象，并非只记录变化的字节。因此，反复覆盖一个大对象，即使可见键数量保持不变，存储成本也可能持续增长。这与块级增量快照的空间模型不同，不能只用修改了多少字节估算对象版本的费用。

启用之前已存在的对象保留 null 版本 ID，新产生的版本化写入不会覆盖那个旧版本。一旦启用，桶就不能回到从未版本化的状态，但可以暂停版本化。暂停期间，后续写入使用 null 版本槽位，可能替换已有 null 版本。讨论覆盖是否安全时，必须明确桶当前处于哪一种状态，不能把暂停与启用混为一谈。

null 是真正的版本标识，不是永久保留保证。null 版本变成非当前版本后，可以受到非当前版本过期规则影响；在授权允许时，也能够按明确版本 ID 删除。因此，列表中出现 null 并不能证明那份旧数据不参与生命周期清理，更不能把它当成永远不会消失的恢复基线。

删除标记改变可见性

启用版本化时，不带版本 ID 的普通 DELETE 创建删除标记。标记处于当前位置后，不指定版本的 GET 通常返回 404；显式请求删除标记的版本 ID 则返回 405。较早数据仍可通过其数据版本 ID 获取，但还受到访问权限、存储类别及加密条件影响。看见 404 不能直接推断底下所有版本已经消失。

删除标记没有对象载荷，却不是免费零字节条目，S3 会按它保存的键名字节收费。删除那个明确的当前标记，可以暴露前一版本，但前一版本本身也可能仍是标记。另一种恢复方式是复制明确的历史数据版本，生成新的当前数据版本，同时保留历史。标记没有数据，不能把它当成普通对象复制来恢复。

按指定 ID 删除数据版本，是另一种永久操作，版本化本身不能把被永久删除的版本找回来。配置 MFA Delete 后，永久删除版本和改变版本化状态会增加相应认证要求，但开启版本化并不会自动开启这种保护。AWS 不支持将 MFA Delete 与生命周期配置一起使用，不能假设所有保护开关可以无条件同时启用。

生命周期表达的是保留取舍

当前版本 Expiration 与 NoncurrentVersionExpiration 各自处理不同对象。启用版本化时，当前数据过期通常创建标记，并把数据变为非当前版本；非当前版本过期则永久删除符合条件的旧数据。资格按成为非当前版本后的时间计算，可选的保留版本数量还会增加另一项条件，并不是简单比较最初上传时间。

生命周期操作异步执行。配置三十天规则，不能证明任何时刻都精确保留三十份版本。过滤范围、写入频率、保留数量、复制状态和 Object Lock 都可能影响资格。转入冷存储保留数据，但会改变存储、取回和最短保存期限等费用。应结合真实对象大小和恢复需求计算，不能只比较表面上的每字节存储单价。

坏掉的样子

普通列表保持稳定时，非当前版本字节仍可能增长并推高费用。应检查版本清单与生命周期实际覆盖范围，而不是期待一个固定的版本数量比率可以诊断所有情况。桶不必像本地磁盘那样物理写满，成本就可能已经失控；生命周期也不是硬性预算上限，更不是唯一可能的保留控制办法。

规则过于激进则会产生相反问题：真正需要恢复的旧版本已经被永久删除。保留窗口应覆盖合理的最迟发现时间和恢复要求。HEAD 能检查元数据，但不会下载并验证对象内容，成功的元数据请求不能当作完成恢复测试。应确认目标版本存在、可读，并且其字节及业务内容确实符合预期。

快速验证

用 Python 3 运行下面模型，保持断言开启。它完全在内存中表示启用版本化的版本栈，其中包含一份原有 null 数据版本。不需要 AWS 账户、凭据或远程对象。删除标记的计费、真实时间、权限、生命周期调度以及并发写入，都明确不在这个简化模型范围内。

versions = [("null", b"old"), ("v1", b"new")]
marker = ("d1", None)
versions.append(marker)
def get_current():
 payload = versions[-1][1]
 return (404, None) if payload is None else (200, payload)
assert get_current() == (404, None)
assert sum(len(data) for _, data in versions if data is not None) == 6
versions.remove(marker)
assert get_current() == (200, b"new")
print("remove current marker: previous data visible")
versions.append(("d2", None))
# Copy an explicit data version to create a new current version.
old = next(data for identifier, data in versions if identifier == "null")
versions.append(("v2", old))
assert get_current() == (200, b"old")
assert any(identifier == "d2" for identifier, _ in versions)
print("copy explicit data version: new current version; history retained")
# Noncurrent null versions are not inherently protected from deletion.
versions[:] = [entry for entry in versions if entry[0] != "null"]
assert get_current() == (200, b"old")
print("remove old null version: current copy remains")

三行输出分别表示暴露上一版本、复制指定历史数据，以及删除非当前 null 版本。创建标记时数据载荷字节仍保留，但这个计数没有包含标记需要收费的键名字节，不能当作真实账单预测。模型也不为生命周期保留数量给出数字保证，因为那需要时间、过滤和其他条件一起参与判断。

真实恢复时，应完整处理分页的数据版本和删除标记列表，并筛选准确键名，避免把同前缀其他对象混进去。选定明确的数据版本之后，取回并验证内容，再决定是否改变生产当前状态。读取历史、验证业务数据、重新发布当前版本是不同动作，需要分别记录结果，不能用一条列表命令代替整套恢复演练。

来源

AWS：S3 版本化，版本化与 null 版本如何工作，已核验 2026-09-16。
AWS：S3 删除标记，删除标记做什么、如何撤销，已核验 2026-09-16。
AWS：S3 生命周期管理，当前与非当前版本的过期和迁移规则，已核验 2026-09-16。
AWS 对象过期，资格条件、永久删除与异步执行，已核验 2026-10-15。
AWS MFA Delete，可选保护及生命周期约束，已核验 2026-10-15。
AWS 恢复旧版本，显式版本复制与恢复，已核验 2026-10-15。

Redis 位图用位而不是存储数字

Thu, 29 Apr 2027 00:00:00 +0000

Redis 位图是把字符串按单个位解释的用法，并不是一种独立的键类型。它适合稠密的是非标记，例如按用户记录每日活跃状态。一千万个连续标志需要一百二十五万个载荷字节，但这个估算不包括键名、对象元数据、分配器额外开销，也不包括业务标识到位偏移的映射，不能直接当成实例总内存。

先定义偏移的契约

SETBIT 在从零开始的偏移处写入零或一，并返回写入前的位值。已经为一的位置再次写一，不会增加成员数量。偏移零对应第一个字节的最高位，偏移八才进入第二个字节。对同一个键执行 GET，读到的是底层字节，它们未必是有效文本，所以二进制数据不应默认按 UTF-8 解码。

GETBIT 对缺失键或超出现有字符串长度的位置返回零，而且不会因为读取就扩容。因此，零不能区分“明确不活跃”与“尚未记录”，需要先决定业务是否允许合并这两种状态。SETBIT 与 GETBIT 要求键的值是字符串；如果键实际是哈希，会报类型错误，不会自动把哈希字段转换成位。BITOP 则会在目标键写入新的字符串。

内存取决于写入过的最高偏移，而不是当前有多少个位为一。写偏移 n 至少需要 floor(n / 8) + 1 个载荷字节，即使要写入的是零也一样。后来把高位清零，并不会缩短字符串。稀疏外部编号因此可能用极少的有效标记触发巨大分配。应验证允许的偏移范围，并采用稳定且足够稠密的编号映射，而不是直接信任任意业务 ID。SETBIT 要求偏移小于二的三十二次方，对应最大五百一十二 MiB 字符串。这个协议上限不是合理的单次请求分配预算，应用应按业务规模设置更小的允许范围。

计数和组合都要明确范围

BITCOUNT 默认检查全部字节。可选的 start 和 end 是包含两端的字节位置；从 Redis 7.0 开始，可以用 BIT 修饰符把它们改为位位置。切换单位只改变查询区间，不会改变键里实际存储的表示。返回值是为一的位数，不是最大的成员编号，也不是位图所能容纳的全部用户数。

BITOP OR 计算成员并集，AND 计算交集。较短的输入和不存在的键，会被视为补零到最长输入的长度。目标键会被新字符串覆盖，原本附在目标键上的过期时间也会移除。因此，派生结果需要明确的寿命策略，不能以为之前给结果键设置过一次期限，以后的重算就会自动继承。

坏掉的样子

BITCOUNT、BITPOS 和 BITOP 都可能遍历大量数据。底层位运算即使经过优化，也不代表全量计算是常数时间；把字符串扩展到远端偏移，还需要分配中间的空间。评估时要同时看偏移跨度、查询频率、派生结果保留多久以及峰值分配。活跃用户很少，并不能证明稀疏位图占用的资源很少。

BITPOS 即使只搜索一个子区间，返回的仍是相对于整个位图的绝对位偏移。不指定结束位置而查找零时，如果现有字符串全是一，就可能返回字符串右侧的第一个位置，相当于认为末尾还有补零。明确同时给出起止边界后，范围内找不到目标位才返回 -1。如果用位图表示固定容量的资源池，这两种查询语义不能混用。

找到一个零也不等于已经预约该位置。两个调用方可能先后读到同一空位，再各自写入；单独的 BITPOS 加 SETBIT 不是一个原子占用动作。如果忽略 SETBIT 返回的旧值，就可能把同一位置分给两个人。同样，合并两天的活跃位图，前提是两份数据使用完全相同的编号映射，否则并集结果即使数值正常，也不再代表同一组用户。

快速验证

原有实验记录使用 macOS、Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0；本轮审阅没有重新执行服务实验，下面的结果说明保留原有观察范围。准备 POSIX 环境、C 编译器、make、curl、tar 与 Python 3.10 或更新版本。安装步骤仅用 libc 构建 Redis 核心，并把客户端装入临时虚拟环境。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

在同一个终端中用 "$redis_lab/venv/bin/python" 执行下面代码。程序仅连接自己在 /tmp 下创建的 Redis Unix socket，关闭 TCP 与持久化，终止自身服务进程后只移除本次运行目录。下载依赖需要网络。实验中最大的位图载荷只有一 MiB，不会为了验证原理而分配前面讨论的巨大偏移。

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance():
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", "noeviction",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


with instance() as client:
 assert client.getbit("missing", 100) == 0
 assert client.exists("missing") == 0
 assert client.setbit("active", 0, 1) == 0
 assert client.setbit("active", 2, 1) == 0
 assert client.setbit("active", 2, 1) == 1
 assert client.type("active") == b"string"
 assert client.get("active") == b"\xa0"
 assert client.bitcount("active") == 2
 print("offset zero is the high bit; repeated SETBIT returns old 1 without adding membership")

 highest = 8 * 1024 * 1024 - 1
 assert client.setbit("sparse", highest, 0) == 0
 assert client.strlen("sparse") == 1024 * 1024
 assert client.bitcount("sparse") == 0
 assert client.setbit("sparse", highest, 1) == 0
 assert client.setbit("sparse", highest, 0) == 1
 assert client.strlen("sparse") == 1024 * 1024
 print("writing a distant zero allocates 1048576 payload bytes; clearing does not shrink")

 client.set("range", b"\x80\x01")
 assert client.bitcount("range", 0, 1) == 2
 assert client.bitcount("range", 0, 1, mode="BIT") == 1
 assert client.bitpos("range", 1, 1, 1) == 15
 client.set("full", b"\xff")
 assert client.bitpos("full", 0) == 8
 assert client.bitpos("full", 0, 0, 0) == -1
 print("ranges default to bytes; BIT changes units; BITPOS returns absolute bit offsets")

 client.set("other", b"\x50\x01")
 client.set("union", b"obsolete", px=60000)
 assert client.bitop("OR", "union", "active", "other") == 2
 assert client.get("union") == b"\xf0\x01"
 assert client.bitcount("union") == 5
 assert client.ttl("union") == -1
 assert client.bitop("AND", "intersection", "active", "other") == 2
 assert client.get("intersection") == b"\x00\x00"
 print("BITOP zero-pads shorter inputs; OR has 5 flags; destination TTL is removed")

 client.hset("hash", "field", b"value")
 try:
 client.setbit("hash", 0, 1)
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("a hash is not converted into a bitmap")
 assert client.hget("hash", "field") == b"value"
 print("bitmap commands reject a hash without converting or replacing it")

偏移零和二组合成字节 0xa0，置位计数为二。对远端位置写零仍然生成一百零四万八千五百七十六个载荷字节；把该位写一再清零，长度保持不变。按字节范围与按位范围计数分别得到二和一，带边界的 BITPOS 结果则仍是绝对偏移，并不会从查询区间起点重新编号。

一个全一字节在无界零查询中返回八，在限定到该字节的查询中返回 -1。OR 得到跨两个字节的五个标记，同时目标键的 TTL 被清除；AND 得到两个全零字节。错误类型访问没有改变原来的哈希。这些结果验证存储表示与命令语义，不代表总进程内存测量，也没有证明并发资源分配正确性或生产吞吐量。

来源

Redis SETBIT，旧位值返回和字符串扩容，已核验 2026-09-08。
Redis GETBIT，缺失键与越界位置的读取，已核验 2026-09-08。
Redis BITCOUNT，置位计数及字节与位区间，已核验 2026-09-08。
Redis BITPOS，绝对偏移与有界零查询，已核验 2026-09-08。
Redis BITOP，结果字符串、补零和操作成本，已核验 2026-09-08。
Redis 8.10.1 构建说明，只编译核心及分配器选择，已核验 2026-09-08。

对象与块存储提供不同的更新契约

Wed, 17 Mar 2027 00:00:00 +0000

块存储通过设备接口暴露可寻址的数据块，对象存储通过接口暴露带名字的对象。仅凭这两个分类，不能决定耐久性、一致性、共享能力或价格。应先列出应用真正需要执行的操作，再核对具体服务的契约。文件系统、数据库和兼容层可以增加行为，但不能让所有底层接口自动变得可互换；一个路径能够被打开，并不证明它符合应用的恢复要求。

比较实际支持的操作

块卷可以先格式化为文件系统，也可以由软件直接管理数据布局。块服务并不一定预装文件系统。应用可以进行小范围覆盖而不必替换整块卷，但共享访问仍然需要协调。把一个卷同时连接到多台机器，不会让普通单机文件系统自动变成集群文件系统。数据库能否恢复，还依赖块接口之上的写入顺序、同步和持久性约定，不能把能够写入等同于断电以后仍然正确。

对象通过桶或其他服务定义的命名空间寻址。普通 S3 通用桶写入会替换整个对象；读取却可以指定字节范围，所以“对象存储每次必须读完整个对象”并不正确。分段上传把多个部分组装成一个完成的对象，不等于通用文件系统的随机写契约。特殊产品还可能提供追加或其他更新能力，因此必须核对选中的桶类型与接口，不能把下面的小模型当成所有产品永远不变的规则。

对象存储通常适合媒体、导出结果和备份文件，让许多客户端按需读取。块存储通常适合数据库文件与虚拟机磁盘。但这只是常见工作负载，并不是互斥分类：数据库可以专门围绕对象接口设计，共享文件系统也可以建立在块设备之上。选择之前应测量请求大小、并发量、恢复过程，以及请求与数据传输的完整成本，不能只比较每月每单位容量的标价。

坏掉的样子

不要默认对象存储采用最终一致性。Amazon S3 对对象写入、删除及对应读取和列举提供强一致性。客户端手里保留旧下载结果，仍然可能看见旧内容，但这不能证明重新向服务读取也会得到旧值。分发缓存、跨区域复制和跨多个对象的业务更新又是不同边界，必须各自检查保证。把这些现象都叫作“对象存储有一致性窗口”，会让排查方向从一开始就偏离事实。

成功的 S3 PUT 不会暴露半个上传对象。请求失败或结果不明时，应确认实际状态，不能直接推断新版本被截断。单个对象的原子替换也无法防止丢失更新：两个客户端可能读取同一旧值，再分别覆盖它。条件请求可以在接受更新之前比较校验标识，但要遵循服务文档中的条件语义。ETag 并不总是内容校验和，更不是把多个键包进同一个事务的承诺。

生命周期删除与历史版本保留应通过真实恢复演练检验。打开版本控制不等于已经有独立备份，在程序里记一个版本数字，也不等于保存了所有旧载荷。大量小对象即使占用字节不多，请求开销仍可能主导成本。兼容挂载层能够接受数据库文件名，同样需要证明它满足锁、写入顺序与失败恢复语义，才能作为合适的数据库存放位置。

快速验证

保存为 storage_semantics.py，用 Python 3.9 或更新版本执行 python3 storage_semantics.py。这是使用虚构字节的独立内存模型，不访问服务，不测文件系统持久性，也不涉及网络延迟与计费。它只把明确写进类定义的规则变成可检查的操作，方便分辨几种常被混淆的保证。

"""In-memory API model, not an implementation of a storage service."""
class BlockVolume:
 def __init__(self, data):
 self.data = bytearray(data)
 def write(self, offset, chunk):
 if offset < 0 or offset + len(chunk) > len(self.data):
 raise ValueError("write outside fixed volume")
 self.data[offset:offset + len(chunk)] = chunk

class ObjectStore:
 def __init__(self):
 self.current = {}
 def put(self, key, data, expected=None):
 old = self.current.get(key)
 version = old[1] if old else 0
 if expected is not None and expected != version:
 raise ValueError("version conflict")
 self.current[key] = (bytes(data), version + 1)
 return version + 1
 def get(self, key):
 return self.current[key]

block = BlockVolume(b"ABCDEF")
block.write(2, b"XX")
assert block.data == b"ABXXEF"
try:
 block.write(5, b"too long")
except ValueError:
 pass
else:
 raise AssertionError("out-of-range write accepted")
assert block.data == b"ABXXEF"
store = ObjectStore()
assert store.put("report", b"ABCDEF", expected=0) == 1
cached = store.get("report")
assert store.put("report", b"XYZ", expected=1) == 2
assert store.get("report") == (b"XYZ", 2)
assert cached == (b"ABCDEF", 1)
try:
 store.put("report", b"stale overwrite", expected=cached[1])
except ValueError:
 pass
else:
 raise AssertionError("stale conditional update accepted")
assert store.get("report") == (b"XYZ", 2)
assert store.get("report")[0][1:3] == b"YZ"
print("PASS: bounded overwrite; complete replacement; cached copy differs; stale condition rejected")

块模型最初有六字节，覆盖中间两字节后，相邻内容保持不变。越界写入被拒绝，原数据没有因此变化。对象模型从第一版的六字节内容，整体替换成第二版的三字节内容；新的读取立即得到替换结果。另一个事先保存的元组仍然包含第一版，因为应用保留了自己的旧副本。这是本地缓存陈旧，不是服务读取出现最终一致性延迟。

使用旧版本发起的条件覆盖失败，最后的断言确认当前对象仍然完整不变。对已经取回的字节做切片，只演示选择一个范围，不是对真实 HTTP Range 请求的测试。末尾 PASS 证明的是这些显式模型规则，不证明厂商实现、跨客户端并发、历史载荷保留、崩溃原子性或灾难恢复。正式使用之前，还应通过所选服务的真实客户端，验证相关操作及失败处理流程，明确哪些结论来自模型，哪些来自系统本身。

来源

Amazon S3 data model，对象操作与强一致性，已核验 2026-10-15。
S3 PutObject，完整对象写入与条件请求，已核验 2026-10-15。
Amazon EBS，块卷与应用管理的文件系统，已核验 2026-10-15。

磁盘调度器给 I/O 排好队，让磁头移动更省

Tue, 09 Mar 2027 00:00:00 +0000

blk-mq 给块层准备了两级队列：每个 CPU 一个软件暂存队列，每条设备队列一个硬件派发队列，而 I/O 调度器就夹在两者之间。一个请求会走最短路径——直接进硬件队列——除非该设备挂了调度器，或者这个请求还能被合并；这两种情况下它要先在软件队列里停留。调度器是整个栈里唯一由内核决定“请求以什么顺序到达设备”的地方。

排序在机械盘上价值极大，在闪存上几乎为零，但调度器还有第二件活，而且这件事在 NVMe 时代依然存在：决定谁先等、谁后等。这两件事的方向并不一致——为磁头效率而重排根本不关心公平，而公平本身要付出寻道的代价——所以当前内核里的四种调度器不是拿来排名的，而是拿来匹配设备与负载的。

磁头才是预算

在 7200 RPM 的盘上，平均每个请求的旋转开销是 4.17 ms，传输一个 4 KiB 块只要 0.026 ms，所以几乎全部服务时间都是寻道加旋转。fixture 重放了 2000 个随机 4 KiB 读、覆盖 100000 条磁道：按到达顺序派发时磁头走过 67907411 条磁道、整轮耗时 21954 ms，约 91 IOPS；按磁道升序派发时只走 99977 条、耗时 8645 ms，约 231 IOPS。同样的请求、同样的设备，磁头行程少了 679 倍，吞吐涨了 2.5 倍。

拆开看才说明问题：寻道在到达顺序那一轮占服务时间的 62%，在排序那一轮只占 3%，而旋转与传输两边都固定在 4.19 ms 每个请求。NVMe 上同一批请求总共只要约 40 ms，且完全没有寻道，所以排序在那里一分钱也买不到。

每种调度器是干什么的

none 就是先到先服务：在内部队列很深且没有竞争的设备上它是对的，在机械盘上是错的，因为寻道那部分开销原封不动。mq-deadline 按扇区排序，并加上分方向的超时——读的超时远早于写，每批的数量由 fifo_batch 限住——于是 none 那种无上界的尾部延迟被收进了边界。kyber 直接盯延迟：哪个队列的请求没达到读或写的目标延迟（read_lat_nsec、write_lat_nsec），它就把那个队列限流，所以一个批量写入方单靠自己无法把交互读推过目标线。

bfq 是公平那一侧的答案：一个支持 cgroup 的比例分配调度器，按权重把设备吞吐——而不只是设备时间——分给进程和分组。它默认偏向低延迟而非高吞吐，并且会让设备空转，这在机械盘上有帮助，在深队列闪存上则可能赔掉吞吐。用 cat /sys/block/<dev>/queue/scheduler 看当前调度器，列表里带方括号的就是生效的那一个；用 echo bfq > /sys/block/sda/queue/scheduler 切换，并靠 udev 规则让它在重启后保持，因为队列属性是每块设备重新创建的。

公平与排序是两个问题

当批量写入方与轻量交互客户端按 90/10 的比例发请求时，先到先服务给轻客户端分到 0.099 的服务量，平均排队位置在 1901 个请求之后——它不是被饿死，而是被淹死。换成分组公平排队，无论混合比例如何它都拿到 0.5 的服务量，代价由那个写入方承担。磁头位置一点没变，变的只是仲裁。

所以在闪存上通常选 bfq 做隔离、选 mq-deadline 要尾部有界，只有单一负载独占设备时才用 none。在机械盘上，排序本身才是更大的收益。用 cgroup v2 的说法，io.weight 给一个组一个份额，io.max 给它一个上限；这两者只有在下面的调度器愿意执行顺序时才有意义。

坏掉的样子

最经典的是机械盘跑在 [none] 上，通常因为主机是从 NVMe 镜像克隆来的，或者 udev 规则匹配了 sd* 而设备其实是 nvme0n1。特征是 %util 顶在 100% 附近、r/s 很低、await 到几十毫秒——设备是忙，不是饱和，而且忙在寻道上。用 cat /sys/block/<dev>/queue/rotational 确认：值为 1 却没有重排调度器，就是那个 bug。

第二种是平均值健康、延迟却崩了。同一个设备上的备份任务或 dd 把交互读饿住，p99 爆掉而均值几乎不动。none 和 mq-deadline 都护不住交互客户端，bfq 或 cgroup 的 io.max 可以。在闪存上还要盯 slice_idle：在没有磁头可保的设备上，为了让单个进程保持顺序而空转，纯粹是白赔吞吐。另外，rotational 为 1 的盘如果只跑 none，iostat -x 里的 aqu-sz（平均队列深度）也会明显偏高，因为请求在队列里等磁头，而不是被合并成一次扫描。

快速验证

看清设备是什么，以及它正跑着哪个调度器：

for d in /sys/block/sd* /sys/block/nvme*n*; do echo "$d rot=$(cat $d/queue/rotational) sched=$(cat $d/queue/scheduler)"; done
cat /sys/block/sda/queue/iosched/read_expire /sys/block/sda/queue/iosched/fifo_batch
iostat -x 2 5
echo mq-deadline > /sys/block/sda/queue/scheduler

第一条把每块设备的旋转标志与当前调度器配对打印，方括号里是生效的那个；rot=1 配 [none] 就是失败特征，rot=0 配 [none] 则正常。第二条给出 mq-deadline 的超时与批量参数。iostat -x 用来区分“饱和”和“只是忙”：%util 高、r/s 低、await 高，说明在排队和寻道，而不是设备到了极限。

来源

Switching Scheduler，调度器名称、sysfs 路径与切换方法，已核验 2026-09-16。
Multi-Queue Block IO Queueing Mechanism (blk-mq)，软件暂存队列与硬件派发队列的关系，已核验 2026-09-16。
BFQ (Budget Fair Queueing)，比例分配行为、cgroup 支持与空转的取舍，已核验 2026-09-16。
Kyber I/O scheduler tunables，Kyber 据以限流的读写目标延迟，已核验 2026-09-16。

停滞的复制槽会继续保留 WAL

Mon, 19 Oct 2026 00:00:00 +0000

PostgreSQL 复制槽记录某个消费者需要保留的材料。一旦槽已经预留日志位置，消费者连接消失，并不会自动解除这份要求。主库可能继续生成日志，而槽的保留起点一直不动。实际风险是磁盘保留量增长，以及追赶还是重建越来越难取舍。槽是否可用，取决于必需日志是否仍然存在，以及实际配置的失效规则。

坏掉的样子

新建物理复制槽不一定立即保留 WAL。如果没有请求立即预留，在槽第一次使用之前，重启位置可能始终为空。因此，仅凭不活跃标志不能量化保留量。需要结合槽类型、预留位置、可用状态和消费者归属来理解。对于逻辑槽，已确认刷新位置描述消费者确认的进度，也不能替代对更早重启位置及其保留义务的分析。

删除槽解除的是这个槽的要求，不一定会在同一瞬间删除文件。检查点清理和其他保留条件仍然有效。别的复制槽、归档积压或日志预留，都可能继续保留文件；回收还可能只是重命名供将来复用，并不把全部已分配字节交还文件系统。多个消费者需要的日志区间可以重叠，所以把每个槽的滞后量简单相加也会重复计算。

保留限制是在两种风险之间做交换。槽的最大日志保留量在检查点附近执行，不是瞬间限制磁盘大小的硬配额。落后足够多的槽可能失去必需日志并变得不可用。这样减少无限保留风险，代价是放弃该消费者现有的追赶路径。仅仅静默时间长，不足以证明可以删除一个仍有真实消费者依赖的槽。

快速验证

在 Linux shell 环境里，以非超级操作系统账户运行脚本，准备 PostgreSQL 18 服务端和客户端程序。本次实际执行版本是 PostgreSQL 18.6。私有临时集群不打开 TCP 监听，客户端通过私有 Unix 套接字连接，里面只有实验用复制槽。少量有日志写入配合强制切段，使保留现象快速可见；这不是对真实业务日志生成量的性能基准。

#!/bin/sh
set -eu
umask 077
lab=$(mktemp -d /tmp/xbcatm-slots.XXXXXX)
mkdir "$lab/socket"
cluster=$lab/data
cleanup() {
 if test -f "$cluster/postmaster.pid"; then
 pg_ctl -D "$cluster" -m fast -w stop >/dev/null
 fi
}
trap cleanup EXIT
initdb -D "$cluster" --no-locale --encoding=UTF8 --auth-local=trust --auth-host=reject >/dev/null
cat >> "$cluster/postgresql.conf" <<CONF
listen_addresses = ''
unix_socket_directories = '$lab/socket'
port = 56432
wal_level = replica
max_replication_slots = 4
max_slot_wal_keep_size = -1
min_wal_size = '32MB'
max_wal_size = '64MB'
checkpoint_timeout = '1h'
CONF
pg_ctl -D "$cluster" -l "$lab/server.log" -w -t 15 start >/dev/null
export PGHOST=$lab/socket PGPORT=56432 PGDATABASE=postgres PGUSER=$(id -un)
export PGCONNECT_TIMEOUT=2
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT * FROM pg_create_physical_replication_slot('unused_slot');
SELECT active,restart_lsn IS NULL FROM pg_replication_slots WHERE slot_name='unused_slot';
DO $$ BEGIN
 IF (SELECT restart_lsn IS NULL FROM pg_replication_slots WHERE slot_name='unused_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'unexpected immediate reservation';
 END IF;
END $$;
SELECT pg_drop_replication_slot('unused_slot');
CREATE TABLE churn (value text);
SELECT * FROM pg_create_physical_replication_slot('held_slot',true);
SQL
segment=$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_walfile_name(restart_lsn) FROM pg_replication_slots WHERE slot_name='held_slot'")
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
DO $$ BEGIN
 FOR n IN 1..8 LOOP
 INSERT INTO churn SELECT md5(g::text) FROM generate_series(1,5000) g;
 PERFORM pg_switch_wal();
 END LOOP;
END $$;
CHECKPOINT;
SELECT active,wal_status,pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)>64*1024*1024
FROM pg_replication_slots WHERE slot_name='held_slot';
DO $$ BEGIN
 IF (SELECT NOT active AND wal_status='extended'
 AND pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)>64*1024*1024
 FROM pg_replication_slots WHERE slot_name='held_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'inactive slot did not retain the expected WAL range';
 END IF;
END $$;
SQL
test -f "$cluster/pg_wal/$segment"
echo inactive_slot_retains_old_segment
psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT pg_drop_replication_slot('held_slot')" >/dev/null
test -f "$cluster/pg_wal/$segment"
echo drop_did_not_immediately_remove_segment
psql -X -v ON_ERROR_STOP=1 -qAt -c CHECKPOINT
test ! -f "$cluster/pg_wal/$segment"
echo checkpoint_released_old_segment_name
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
ALTER SYSTEM SET max_slot_wal_keep_size='32MB';
SELECT pg_reload_conf();
SQL
attempt=0
while test "$(psql -X -v ON_ERROR_STOP=1 -qAt -c "SELECT current_setting('max_slot_wal_keep_size')='32MB'")" != t; do
 attempt=$((attempt+1))
 test "$attempt" -lt 100 || exit 1
 sleep 0.1
done
psql -X -v ON_ERROR_STOP=1 -qAt <<'SQL'
SELECT * FROM pg_create_physical_replication_slot('limited_slot',true);
DO $$ BEGIN
 FOR n IN 1..8 LOOP
 INSERT INTO churn SELECT md5(g::text) FROM generate_series(1,5000) g;
 PERFORM pg_switch_wal();
 END LOOP;
END $$;
CHECKPOINT;
SELECT wal_status,invalidation_reason FROM pg_replication_slots WHERE slot_name='limited_slot';
DO $$ BEGIN
 IF (SELECT wal_status='lost' AND invalidation_reason='wal_removed'
 FROM pg_replication_slots WHERE slot_name='limited_slot') IS NOT TRUE THEN
 RAISE EXCEPTION 'slot limit did not invalidate the test slot';
 END IF;
END $$;
SELECT pg_drop_replication_slot('limited_slot');
SQL
printf 'lab_directory %s\n' "$lab"

第一个物理槽创建时不立即预留。输出中的假与真，分别表示槽不活跃、重启位置为空。脚本对此作出断言，再删除这个尚未使用的夹具。下一个槽明确请求预留，而且始终没有消费者连接。经过写入、切段和检查点后，观察到不活跃、保留范围超出最大 WAL 目标，以及按日志位置差计算落后超过六十四兆二进制字节的状态。

脚本先检查最初需要的日志段仍然存在，再删除这个测试槽，并确认文件随即仍在。后续检查点之后，旧日志段名字才消失。这些结果把解除保留要求与立即完成文件系统清理区分开来，并不声称整个日志目录一定变空，也不声称原空间被回收后就一定从文件系统占用中消失。

最后一阶段设置三十二兆二进制字节的槽保留限制，核对配置重新加载已经生效，再预留一个新槽。继续写入和切段，使它超过限制。检查点之后，必须得到日志已经丢失、失效原因是必要日志被移除的结果；断言核对可用状态与原因。这里观察到的是槽的恢复路径丢失，不是某个备库成功追赶到了当前位置。

脚本只删除自己的测试槽，退出时停止临时服务，并打印保留日志与数据的目录，便于复核。整个演练不会断开或重建真实消费者。需要清理的是实验专属资源，生产里该不该放弃某条复制链路，仍然要由消费者归属与恢复承诺决定，不能机械照抄测试中的删除动作。

根据归属与可恢复性作决定

监控重启位置、日志状态、安全余量、不活跃时间、实际保留字节以及剩余空间。安全余量为空，可能表示没有设置保留上限，也可能表示槽已经失效，所以必须结合其他字段解释。PostgreSQL 18 还提供明确的失效原因，可以区分日志被移除与其他原因，避免单纯根据静默时长猜测。

退役一个槽之前，要找到它的所有者，并确认消费者是否还会恢复。何时应重新建立副本，何时应继续保留历史，应当明确选择。若必要日志已经消失，事后调大限制并不会重新生成它。只有替代消费者从一致起点建立起来，并且持续向前推进，才能把这次事件视为恢复。单纯看到磁盘曲线下降，不能证明复制服务也恢复了正常。

来源

PostgreSQL 18 复制槽视图，预留位置、可用状态、安全余量与失效原因，已核验 2026-09-12。
PostgreSQL 18 复制配置，在检查点执行的复制槽日志保留限制，已核验 2026-09-12。
PostgreSQL 18 管理函数，物理槽创建、立即预留及删除接口，已核验 2026-09-10。

S3 存储类用成本换访问方式

Wed, 30 Sep 2026 00:00:00 +0000

存储类改变的不只是每月保存字节的价格，还包括取回方式、故障韧性和计费结构。首先应确定业务允许多久恢复数据，以及丢失后是否有其他可重建副本。Standard-IA 可以立即读取，但取回另行收费；Glacier Flexible Retrieval 和 Deep Archive 则需要先恢复，再执行普通读取。One Zone-IA 还有不同故障边界：它不能抵御所在可用区被物理摧毁。相同的宣传持久性数字，不能替代对实际故障域的判断。

先拆清费用，再比较总额

使用桶所在区域的当前价目表，明确存储类、取回档次与请求种类。存储取决于计费容量和持续时间；取回可能同时按字节及请求计费。逐对象迁移请求和归档元数据则随对象数量增长。不能把所有费用都说成只由对象数量决定，也不能从某一条存储单价直接推出整个工作负载的节省比例。同样大小的数据拆成大量小对象，成本模型可能完全不同。

不要把 Flexible Retrieval 和 Deep Archive 的标准取回统一当成免费。AWS 明确提供 Flexible Retrieval 批量取回及其请求免费，Intelligent-Tiering 则有另外的标准和批量取回免费规则。这些例外不能推导出其他存储类和档次也免费。归档恢复后，原归档对象仍在；临时可读副本还会按选定保留时间收取 Standard 存储费。只计算原归档的低价，会漏掉这个并存阶段。

即使对象提前消失，最短存储期限仍然影响费用：Standard-IA 和 One Zone-IA 为三十天，Glacier 即时与灵活取回为九十天，Deep Archive 为一百八十天。提前删除、覆盖或迁出可能产生剩余期限费用。Standard-IA、One Zone-IA 和 Glacier Instant Retrieval 有 128 KB 的最小计费对象大小；灵活取回与深度归档则每对象增加四十 KB 元数据，分别按 Standard 与归档费率计费。

生命周期规则必须对应工作负载

对象年龄不是距离上次访问的时间。三十天后迁移的规则，也会命中一份已经保存一年、却仍然每周读取的报告。需要同时评估对象尺寸、取回字节数、请求频率、保留时间及可接受的恢复延迟。前缀和标签可以分开不同工作负载，但只有分类长期准确时才有效，不能把存储时间长直接解释为访问已经变少。

二零二四年九月开始的新默认行为，阻止小于 128 KB 对象的生命周期迁移。没有修改的旧配置可能保留此前行为，显式大小过滤器也可以覆盖默认限制。因此，一个小对象仍在 Standard，不能独自证明规则已经坏了。应检查配置实际生效的过滤条件和变更历史，再判断它为何保留原存储类，而不是看到某次查询结果就猜测迁移失败。

坏掉的样子

存储小计下降，可能掩盖取回和请求费用上升。反过来，已经恢复的临时副本在有效期内被多次读取，也不一定每次都重新发起归档恢复。应按真正的“恢复后读取”流程建模，把临时副本存储算进去，不能机械地将归档恢复费用乘上每一次 GET。访问频率与恢复请求频率有关，却不是同一个数。

恢复耗时同样是运维依赖。灵活取回的标准请求通常需要三至五小时；深度归档的标准请求通常在十二小时内完成，批量通常在四十八小时内完成。这是文档描述的典型预期，不是无条件的截止保证。承诺恢复时间目标之前，应实际演练恢复并确认完成；请求已接受、恢复正在进行和内容已经可读，是不同阶段。

快速验证

用 Python 3 运行下面独立脚本；本轮以 Python 3.12.14 执行。价格是刻意虚构的教学输入，不是当前 AWS 报价，也不是完整账单。模型比较一个 GiB 保存十二个模型月份，假定每次读取都取回整个对象。把参数说清楚之后，才可以讨论为什么访问量变化会让选择反转。

from decimal import Decimal as D

# Invented rates, not an AWS quote; one GiB held for twelve modeled months.
warm_storage = D("0.02")
cold_storage = D("0.01")
retrieval_per_gib = D("0.01")
transition_per_object = D("0.001")


def annual_cost(full_reads):
 warm = 12 * warm_storage
 cold = 12 * cold_storage + full_reads * retrieval_per_gib + transition_per_object
 return warm, cold


assert annual_cost(0) == (D("0.24"), D("0.121"))
assert annual_cost(52) == (D("0.24"), D("0.641"))
assert annual_cost(11)[1] < annual_cost(11)[0]
assert annual_cost(12)[1] > annual_cost(12)[0]
small_bytes, minimum_bytes = 10 * 1024, 128 * 1024
assert D(max(small_bytes, minimum_bytes)) / small_bytes == D("12.8")
assert max(10, 180) == 180 # Illustrative minimum-duration billing boundary.
for reads in (0, 11, 12, 52):
 print(reads, "full reads:", tuple(map(str, annual_cost(reads))))
print("10 KiB under a 128 KiB floor: 12.8x billable size")
print("Excluded: GET requests, transfer, restored copies, tax, and negotiated rates")

零次读取时，较冷模型的 0.121 低于 0.24；五十二次完整读取后，0.641 反而高于 0.24。在这组输入下，十一次仍便宜，十二次就不再便宜。尺寸计算展示小对象起计门槛为何需要独立处理。这些结果都不是通用的存储类切换阈值，也没有验证云服务上的实际迁移或计费。

下面保留原有 AWS CLI 诊断命令。需要已授权桶的读取权限，并替换 B 与 K；本轮没有执行这些命令：

aws s3api list-objects-v2 --bucket B --query 'Contents[].StorageClass' --output text | tr '\t' '\n' | sort | uniq -c
aws s3api get-bucket-lifecycle-configuration --bucket B --query 'Rules[].[ID,Status,Transitions[0].Days,Transitions[0].StorageClass]' --output table
aws s3api head-object --bucket B --key K --query 'StorageClass'

清单成功且非空时，第一条按存储类统计当前对象个数，不统计字节或非当前版本。空清单和 CLI 错误需要另外处理；管道退出成功，本身不证明 AWS 调用成功。第二条只显示每条规则的第一个迁移，遗漏过滤条件、后续迁移与非当前版本迁移，决策前必须检查完整响应。HeadObject 对 Standard 不返回 StorageClass，所以投影为 null 本身不是故障。这些查询都不能测量访问频率，也不证明尚待处理的迁移或恢复已经完成。应结合完整策略、清单、访问证据与账单之后再改变生命周期行为。

来源

AWS S3 pricing，计费维度、恢复副本与免费取回例外，已核验 2026-10-15。
AWS storage class guide，访问、韧性、最短期限与最小计费尺寸，已核验 2026-10-15。
AWS lifecycle transitions，小对象默认行为及旧配置差异，已核验 2026-10-15。
AWS archive retrieval options，典型恢复时长，已核验 2026-10-15。
AWS CLI HeadObject，Standard 不返回 StorageClass，已核验 2026-10-15。
AWS CLI ListObjectsV2，清单范围与对象字段，已核验 2026-10-15。
AWS CLI lifecycle configuration，过滤器及迁移数组，已核验 2026-10-15。

存储 · XB 现场笔记

LVM 快照在时间上定格一块块设备

异常存储，不是副本

耗尽即失效

合并回滚，以及 thin 如何改变失败形态

坏掉的样子

快速验证

来源

ZFS 快照给文件系统一个回退键

为一个一致的树命名

空间在哪里：zfs list -o space

hold、diff 与版本对比

坏掉的样子

快速验证

来源

高基数标签在查询之前就增加存储序列

统计实际组合，而不是孤立取值

查询少几行，不代表少存几行

使用正确范围的清单诊断增长

坏掉的样子

快速验证

来源

checkpoint 把脏缓冲刷到磁盘

坏掉的样子

快速验证

同时考虑恢复与前台负载

来源

分区把一张表拆成很多看起来还像一张的片段

逻辑父表与物理子表

分区键不只影响路由

坏掉的样子

快速验证

来源

Redis AOF 用速度换持久性

执行、记录与确认不是同一步

按确认语义选择同步策略

重写产物是一组文件

坏掉的样子

快速验证

来源

Btrfs 快照是写时复制，不是复制

共享 extent，而不是复制数据块

空间到底去了哪里

还原点不是副本

坏掉的样子

快速验证

来源

LRU 缓存淘汰最久未用的条目

沿访问顺序找出淘汰对象

精确顺序与采样近似不是同一契约

容量约束不是新鲜度约束

坏掉的样子

快速验证

延伸阅读

来源

LSM 树把前台写入成本转移到后续归并

缓冲改变工作的发生时机

读取仍然需要处理多个版本

坏掉的样子

快速验证

来源

稀疏文件把逻辑长度与分配块分开

坏掉的样子

快速验证

为需要的表示做预算并保留它

来源

PVC 为 Pod 提供容器之外的持久存储

声明、卷与绑定

删除顺序与 finalizer

回收策略：Delete 还是 Retain

坏掉的样子

快速验证

来源

NFS 把远程目录通过网络共享出去

文件与表

选项真正决定了什么

挂载，以及 id 映射陷阱

坏掉的样子

快速验证

来源