存储 · XB 现场笔记

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

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

经典 LVM 快照是在源逻辑卷上附加写时复制异常存储。lvcreate -s -L 5G -n snap vg/data 请求五 GiB 存储，实际分配还受卷组空闲容量和分配粒度约束。创建时不需要复制整份源卷，但不代表完全没有工作或必然瞬时完成。thin 快照使用另一种共享池机制，不能把经典快照的独立异常存储套到所有 LVM 快照上。

异常存储要覆盖整个保留窗口内发生变化的不同 chunk 及其元数据，包括备份复制期间的写入。突发负载可能比安静时估算更早耗尽容量。经典存储满后快照会失效，读取开始返回错误。应提前观察有效状态和增长趋势，留下扩容或结束备份的时间；只规定一个百分比告警，而没有响应能力与空闲空间，不能形成可靠恢复计划。

异常存储，不是副本

源使用 snapshot-origin 目标，snapshot 则把未变化的源 chunk 与保存的异常组合成视图。直接写快照的数据进入它自己的 COW 设备。对已保存异常的同一 chunk 反复修改，不需要为这份快照再保存一次原始内容。原文一百万次写入、十六个热块却只有十五个异常的数字，没有找回轨迹；若十六个不同 chunk 都写过，就需十六份数据异常，另加元数据。

lvs -a -o lv_name,lv_attr,origin,data_percent,lv_size 展示类型、状态和用量。swi-a-s--- 只是示意，不是所有快照固定的属性串；第五位 I 表示无效快照。告警应覆盖实际增长速率和处理时间。lvextend 需要 VG 中有可分配空间；lvchange --monitor y 只启用监控，自动扩容还依赖 dmeventd、有效扩容策略及足够容量，并不是一个开关就能保证成功。

耗尽即失效

内核文档说明，经典 COW 存储耗尽后会禁用快照并返回错误。lvcreate 手册中按源容量百分之二十创建的命令只是例子，不是通用容量建议。规划要包含 chunk 粒度、元数据、突发变化及完整备份时长。在耗尽之前扩容才有助于维持有效快照；恢复点已经失效时，不能因为 LV 名字仍在，就把它当作内容完整的历史状态。

经典快照溢出时源卷写入通常继续，但这不保证源卷或底层设备不会同时出现其他问题。无效快照不能再作为可用恢复点，却不等于它从未存在；此前已经完成并验证的独立备份可能仍有效。当前快照是否可读，与另一处已完成副本是否完整，应分别核对。不能用夸张的比喻替代这两个不同状态，也不能以源服务还在运行推断快照健康。

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

lvconvert --merge vg/snap 将持久化 COW 快照合并回源，并消耗该快照。源与快照两个 LV 都未打开时立即开始，否则延后至二者关闭时的激活机会。合并开始后源可以继续服务读写，必要的受影响写入会等待对应 chunk 完成。这里不保证回滚全程无需中断，而且源上较新的数据可能被丢弃；停用应用、关闭使用者和确认恢复目标都需要明确安排。

thin 快照与其他 thin LV 共用池的数据及元数据容量，不拥有单独定额的经典 COW 存储。数据空间满时，依策略可能先排队写入，也可能立即返回错误；元数据耗尽又是另一种失败。问题可以影响多个卷及文件系统，却不等于每个卷瞬间全毁。必须同时监控池的两种百分比、满池行为与可扩容能力，不能只观察某一份快照的虚拟大小。

坏掉的样子

块级快照不会自动成为应用一致的备份。文件系统与数据库缓冲、日志，以及跨卷存放的数据，都需要协调并在还原时正确恢复。复制过程中要检查快照有效性、传播读取错误，之后验证内容与还原结果。命令成功退出或挂载成功都不能证明备份完整；本轮没有进行 LVM 创建、耗尽、扩容或合并实验，也没有用一个内存模型替代这些系统验证。

安排合并前，应识别源与快照双方的打开者，规划应用停机或激活边界。先在一次性卷上演练，并另留独立备份。容量要覆盖整个保留窗口的不同块变化，不能只按其中最忙一小时计算。完成后还需确认实际卷及应用状态，不能仅凭分配计数下降宣布恢复成功。原来的设备名也必须绑定到测试目标，不能直接借用生产卷路径。

LVM 保留变化前的 chunk：机制图。

快速验证

以下原命令保持不变并暂缓执行。名称依赖具体环境，也需要已授权的 LVM 访问；其中 lvextend 会改变分配，因此整段不是只读诊断。本轮未执行 device-mapper、内核、逻辑卷或挂载操作，不能把这些命令列在文章里就说验证已完成：

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% 与有效状态，不同于 thin 池的 Data% 和 Meta%。dmsetup status 格式取决于目标类型：普通快照分配不必下降，而 snapshot-merge 可向仅剩元数据的状态递减。最后一行既不证明 VG 有空闲容量，也不能使无效快照复活。完整实验需要绑定目标并逐步验证状态变化，相关可执行修改单独保留为暂缓提案。

来源

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。
lvconvert(8)，立即与延后合并以及卷打开状态条件，已核验 2026-10-18。
PostgreSQL filesystem backup，一致快照范围、WAL 与多卷恢复要求，已核验 2026-10-18。

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

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

ZFS 快照通过写时复制引用保留某一时点的数据集视图，不需要把全部数据另复制一遍。只要还有引用需要旧块，它们就继续保留。但创建仍涉及元数据与同步工作，不能承诺零分配，也不能把在提示符重画之前返回当作实测保证。本次没有运行 ZFS，保留文件中也未找到原文所称实验的原始输出，所以数值与运行效果必须单独限定来源。

这样的历史适合本地恢复，但 tank/data 的快照仍位于同一个池。让池不可用的故障，也可能让全部快照不可用。这描述的是共享故障边界，不是断言每次控制器故障都会原子地毁掉所有块。独立备份或复制还需要自己的保留策略及恢复验证，不能仅因另一处存在相同名字，就宣布已经获得完整灾难恢复能力。

为一个一致的树命名

快照原子地捕获数据集的文件系统状态；递归 -r 会让后代数据集在同一时刻建立快照。不递归时，子数据集被遗漏，并不是自动晚一点另拍一份。文件系统一致不等于应用检查点：数据库缓冲、日志以及选定数据集之外的文件，仍需遵循应用支持的备份或崩溃恢复流程。必须协调所有必要部分，才能把整组状态作为可恢复对象。

tank/data@daily-2026-09-16 这样的名字可以辅助保留策略，还应结合创建时间、属性与备份记录；名字本身不是删除资格的证明。zfs list -t snapshot -o name,used,refer,creation -s creation 用于观察快照及空间统计，真正清理之前还要检查依赖和 hold。自动命名也可以被可靠管理，关键是保留规则有明确、可追溯的依据。

空间在哪里：zfs list -o space

zfs list -o space tank/data 选择 NAME、AVAIL、USED、USEDSNAP、USEDDS、USEDREFRESERV 与 USEDCHILD，不包含 REFER。USED 分解为四项 used-by 类别，不能写成 REFER 加 USEDSNAP。REFER 表示数据集可访问的数据，其中也可能有共享块。单份快照的 USED 统计其独有引用，删除其他快照还会改变这个值，所以逐份相加不等于整体可回收空间。

原文三十份快照、六十四 MiB 数据集以及每日两 MiB 变化的数字，没有找回对应 ZFS 运行轨迹。六十 MiB 与一千九百二十 MiB 的对比只能当作示意算术，不能作为真实分配结论。元数据、压缩、块尺寸、共享关系及确切保留时间线都会影响成本。新快照独占很少，并不代表整组历史没有阻止大量空间回收。

hold、diff 与版本对比

用户 hold 会阻止销毁，直到明确释放。zfs hold keep tank/data@daily-2026-09-16 设置一个标签；zfs holds tank/data@daily-2026-09-16 检查它，zfs release keep tank/data@daily-2026-09-16 释放该标签。hold 可保护传输中的快照，但克隆源依赖是另一种关系，不一定显示成具名 hold 标签。释放前要弄清依赖的任务，而不是看到忙就盲目取消保护。

zfs diff tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 比较仍保留的两个版本，报告新建、删除、修改与重命名路径。文件系统快照会按需挂载到 .zfs/snapshot/<name> 之下，snapdir=visible 让目录出现在列表里。读取旧文件与破坏性回滚整个数据集是不同恢复选择，两者本身都没有证明应用业务状态正确。

坏掉的样子

成功发送并接收到独立保护的存储，才可能在源池丢失后保留数据。所示增量传输要求目标已存在，而且最近快照匹配发送基线；只有增量流不构成完整独立备份。同机第二个池仍可能共用电源、控制器或管理员权限，因此不能只数池的个数判断隔离。必须核对接收内容并演练可用还原，才能说明它抵御了哪些故障。

USEDSNAP 上升应触发容量与保留检查，但池占用超过百分之八十不是统一的写失败阈值，还要观察配额、预留及实际可用空间。克隆依赖源快照，删除源或回滚越过较新依赖时需要有意识地处理关系。回滚会丢弃较新数据，而销毁克隆并非唯一恢复策略。可以选择恢复文件或另建恢复数据集，不应把破坏性递归操作当作自动下一步。

ZFS 历史存在依赖：机制图。

快速验证

以下独立运行的 Bash 配方尚未执行。它要求独占控制的一次性数据集、已存在的源快照，以及此前已从基线完整接收的目标。目标自基线以来必须未被修改，并挂载在绑定路径；路径中不能有中间挂载或符号链接，所用 hold 标签必须尚未占用。创建目标时点的源快照前，先在源数据集中准备普通文件 probe.txt，并把可信的外部预期副本放到 expected 路径。列表递归检查快照，但传输只覆盖 tank/data 本身，不包含后代数据集；不能把递归列出误当成递归复制。

(
 set -euo pipefail
 src='tank/data'
 dst='backup/data'
 base='daily-2026-09-15'
 next='daily-2026-09-16'
 tag='example-transfer'
 mount='/mnt/zfs-lab/received'
 expected='/mnt/zfs-lab/expected-v2.txt'

 zfs list -r -t snapshot -o name,used,refer,creation -s creation "$src" "$dst"
 zfs list -o name,avail,used,usedsnap,usedds,usedrefreserv,usedchild,refer "$src"
 zfs holds "$src@$base" "$src@$next"
 zfs diff "$src@$base" "$src@$next"

 latest=$(zfs list -H -r -t snapshot -o name -s createtxg "$dst" |
 awk -F@ -v dataset="$dst" '$1 == dataset { last=$0 } END { print last }')
 test "$latest" = "$dst@$base"
 source_guid=$(zfs get -Hp -o value guid "$src@$base")
 target_guid=$(zfs get -Hp -o value guid "$dst@$base")
 test -n "$source_guid"
 test "$source_guid" = "$target_guid"
 target_mount=$(zfs get -H -o value mountpoint "$dst")
 target_mounted=$(zfs get -H -o value mounted "$dst")
 test "$target_mount" = "$mount"
 test "$target_mounted" = yes
 test -f "$expected"
 test ! -L "$expected"

 zfs hold "$tag" "$src@$base" "$src@$next"
 zfs send -i "$src@$base" "$src@$next" | zfs receive "$dst"
 source_guid=$(zfs get -Hp -o value guid "$src@$next")
 target_guid=$(zfs get -Hp -o value guid "$dst@$next")
 test -n "$source_guid"
 test "$source_guid" = "$target_guid"
 test -f "$mount/.zfs/snapshot/$next/probe.txt"
 test ! -L "$mount/.zfs/snapshot/$next/probe.txt"
 cmp -- "$expected" "$mount/.zfs/snapshot/$next/probe.txt"
)

目标最近快照及基线 GUID 必须匹配，仅有相同名字不够。断言失败会停止子 shell，pipefail 会暴露管道任一端的失败。接收后 GUID 和测试文件字节一致，仍不能证明完整应用可还原：必须另行核对完整清单、元数据与应用恢复。无论成功或失败，已创建的 hold 都保留；完成验证与依赖检查后，仅用 zfs release example-transfer tank/data@daily-2026-09-15 tank/data@daily-2026-09-16 释放本实验标签。示例不包含强制回滚或自动清理，存储运行与完整恢复验证仍暂缓。

来源

zfs-snapshot(8)，快照创建语义与递归快照，已核验 2026-09-16。
zfs-list(8)，space 列集与独立的 REFER 属性，已核验 2026-09-16。
zfs-hold(8)，hold、zfs holds 以及销毁返回的 EBUSY，已核验 2026-09-16。
zfs-send(8)，增量发送流及其基线快照要求，已核验 2026-09-16。
zfsprops(7)，used-by 分解、共享引用、配额与预留，已核验 2026-10-18。
zfs-clone(8)，克隆对源快照的依赖，已核验 2026-10-18。
zfs-rollback(8)，较新数据丢弃及依赖克隆处理，已核验 2026-10-18。
zfs-receive(8)，增量接收要求匹配目标基线，已核验 2026-10-18。
PostgreSQL filesystem backup，一致快照范围、WAL 与多卷恢复要求，已核验 2026-10-18。
ZFS concepts，克隆对源快照的依赖与共享存储边界，已核验 2026-10-18。
zfs-get(8)，用于 GUID 与挂载点检查的精确属性读取，已核验 2026-10-19。

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

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

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

查询聚合减少返回行数；在生产端累计所需的路由总量才会减少导出的身份。数字示意原文的固定总量样例；本轮未重跑 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 大小则涉及回收并预留文件供以后复用，不是另一条强制触发检查点的阈值。如果理解错这些参数，可能一边看到检查点间隔正常，一边忽略实际上还在持续增长的归档积压。

维护进度与事务可见性分开；最终值 11 有断言，检查点比较是观察。双会话运行仍待验证。

快速验证

准备一台安静的 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 会忠实保留应用误操作的效果，所以仍需独立留存备份。进程重启成功并不能证明断电安全、复制确认或业务恰好执行一次。

AOF 恢复依赖一致清单及活动基础、增量文件。同步策略约束确认语义；原文 SIGKILL 重启检查中操作系统仍运行，不构成断电保证。

快速验证

准备 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 快照是带有源初始内容的新子卷，通过共享已有文件 extent 保留视图，而不是逐块复制全部数据。创建会复制根部元数据，也可能等待源中的脏数据刷出，因此不能承诺无论大小都在毫秒内完成。同一 extent 还可能同时被多个快照或 reflink 引用，不存在固定只能引用两次的规则。共享数据与完全没有创建成本，是不同的判断。

快照让本地恢复点较为经济，但成本包含元数据以及后续分岔保留下来的旧块。它与源共用整个文件系统的存储池，而文件系统可能跨多块设备，并不一定只在一块磁盘上。快照数量持续增加时，已删除或覆盖的数据仍可能被保留。即使设置为只读，同一文件系统内的快照也不是独立备份，不能把版本数量当作故障隔离程度。

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

快照是有独立根的子卷。示例 btrfs subvolume snapshot -r "$src" "$snap" 请求只读快照，普通快照则可以写入。只读标志限制通过这个子卷进行的普通修改，不防管理员删除或底层损坏。快照不是递归操作：嵌套子卷在其中只是空的占位目录，其内部文件不会自动包含进来。恢复计划必须另行处理这些子卷，不能只检查顶层目录是否存在。

共享 extent 被修改时，写时复制为其余引用保留旧内容。实际分配受到 extent 布局、压缩、元数据和后续快照影响，不能简单等同于应用写了多少字节。原文中的 APFS 克隆数字不是 Btrfs 测量，本次也没有找到其原始轨迹；不能用它们证明创建零成本，或同一范围第二次覆盖时 Btrfs 一定不再分配。跨文件系统类比只能解释思路，不能替代本系统验证。

空间到底去了哪里

btrfs filesystem du 通过 FIEMAP 报告文件 extent 的 Total、Exclusive 和 Set shared。每个参数各自定义递归扫描的文件集合，Set shared 统计该集合引用的共享范围并处理重叠，并非只统计与其他命令行参数之间的共享。compsize 显示面向压缩的 Disk Usage、Uncompressed 与 Referenced，不是相同三列。qgroup 则要求先启用配额并保持统计一致，不能把缺失统计解释成零占用。

删除源不会释放仍由快照或 reflink 引用的 extent；只有其他引用都消失时，它才可能成为某个快照的独占数据。删除子卷还分为移除目录和后台清理两个阶段，所以空间不一定立即归还。df 反映文件系统整体容量，不能把每个未释放字节精确归到某一份快照。设计保留周期时，需要同时考虑共享关系与后台回收，而不是只数目录数量。

还原点不是副本

本地快照可以保留有用的文件系统视图，却不自动保证应用一致性。数据库可能需要协调备份步骤、保留日志，并在还原后执行恢复；应用尚未交给文件系统的缓冲内容不在快照里。源与快照也共享底层故障风险。回滚并非固定时间完成的保证，更不能替代应用启动及内容正确性的验证；文件能列出和业务能恢复，应分别记录。

btrfs send 生成供另一个文件系统的 btrfs receive 使用的数据流。增量 -p 依赖两端都存在且未被改变的合适父快照，参与发送的所有快照都必须只读。独立存储只能隔离它没有共同承受的故障，还要验证接收成功、保留策略和还原内容。快照频率更高也不保证每次传输都按固定比例缩小，变化模式和参考快照同样影响结果。

坏掉的样子

删除大目录后空间几乎不变，应先检查快照及 reflink 引用，再决定是否继续删除。btrfs filesystem du -s 与 qgroup 提供不同口径，某一个 Exclusive 值不一定解释全部差额。清理恢复点之前还要核对保留要求和发送依赖。多个快照可能共同保留某些块，即使没有任何一份单独独占它们，所以不能仅按最大独占值猜测可释放容量。

写时复制需要为数据及元数据保留分配余量。用 btrfs filesystem usage 分别观察两者；设备尚未分配的空间，与已分配块组内部仍空闲的空间不是同一指标。不能从这些计数推出统一百分之五余量就足够，也不能断言两种空间总按固定顺序耗尽。一次分配失败本身同样不证明文件系统已切成只读，应结合真实错误与状态判断。

Btrfs 共享 extent：机制图。

快速验证

以下是尚未执行的有限检查。它要求已授权的一次性源子卷 /mnt/btrfs-lab/data、同一 Btrfs 文件系统中已存在的 snapshots 父目录，以及所需工具和权限。所有路径组件必须无符号链接，并在整个检查与创建过程中由本实验独占控制。目标若已是目录，Btrfs 会改变实际创建位置；下方检查拒绝已存在的路径，也拒绝悬空符号链接。这个检查不是防竞态的锁，无法保证独占控制时应停止，不能把示例默默套到生产路径。

(
 set -eu
 src='/mnt/btrfs-lab/data'
 snap='/mnt/btrfs-lab/snapshots/data-2026-09-16'
 if [ -e "$snap" ] || [ -L "$snap" ]; then
 printf '%s\n' 'Refusing an existing snapshot destination.' >&2
 exit 1
 fi
 btrfs subvolume snapshot -r "$src" "$snap"
 btrfs filesystem du -s "$src" "$snap"
 compsize "$snap"
 btrfs filesystem usage "$src"
)

快照创建与随后的 du、compsize 使用绑定的同一目标；重复运行会拒绝该目标，不会自动删除快照。文件 extent 计数不测量全部快照元数据。Exclusive 等于 Total，只说明当前 extent 不再共享，不能证明该子卷从来不是快照。这不是分岔或还原实验：后续仍须记录已知测试文件的原始字节，确认源与快照起初相同，仅修改源，再确认快照保留旧字节、源包含新字节。相关存储检查及应用恢复仍暂缓，不能把语法通过视为运行通过。

来源

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。
compsize upstream manual，压缩与引用尺寸统计不同于 filesystem du，已核验 2026-10-18。
PostgreSQL filesystem backup，一致快照范围、WAL 与多卷恢复要求，已核验 2026-10-18。

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 能保持多线程下内部结构一致，但同时发生的未命中仍可能让被包装函数执行多次。线程安全不等于抑制同一项工作被重复执行。

访问 A 后，淘汰对象变成 B。依据原文绘制机制；模型值与原文报告的观察不代表本次运行测试。

快速验证

将代码保存为 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 描述存储，声明请求存储，由控制器安排绑定或供应。真正的恢复仍取决于后备存储、可用拓扑与备份；有了 StorageClass，可以由 provisioner 动态供应，而不必预先建好每块卷。

声明与卷各自有独立的生命周期。finalizer 可以推迟对象删除，回收策略决定释放后的存储如何处理。维护前应核对两者：处理失误可能留下持续 Terminating 的声明、删掉本想保留的数据，或留下一份没人在用却仍在计费的存储。

保护机制推迟删除，不证明控制器健康。Retain 需要核对归属、备份并按提供方流程决策。保留诊断仍受阻，本轮未重跑。

声明、卷与绑定

普通匹配会检查容量、访问模式、存储类、volumeMode、选择器及既有归属。不匹配的声明可以停在 Pending，应检查事件与 StorageClass，不能只猜一个原因。绑定不证明拓扑可用：显式指定 PV 时，即使节点亲和性冲突也可能绑定成功，后续调度与挂载仍需各自成功。已释放但尚未回收的 Retain 卷也不会自动成为新声明的可用备件；旧 claimRef 可能仍然存在。

accessModes 没有默认值。ReadWriteOnce 允许单节点读写挂载，该节点上的多个 Pod 仍可能共用它，不是单 Pod 独占。ReadWriteOncePod 才为受支持的 CSI 卷提供单 Pod 约束；访问模式本身并不在挂载后执行写保护。Immediate 不等待消费者就开始绑定或供应，受拓扑限制的存储可能因此无法使用。受支持的 WaitForFirstConsumer 则结合消费 Pod 的调度约束协调存储，之后才完成放置；它不是先完成调度再随意创建卷。

删除顺序与 finalizer

通常先停用 Pod，再处理声明与卷。删除仍在使用的声明会记录 deletionTimestamp，但 kubernetes.io/pvc-protection 可以推迟对象消失。Kubernetes v1.34.0 对普通 PVC 引用的检查只计入已经分配节点的 Pod；仅有未调度 Pod 引用，并不会维持这项保护。这是控制器的引用检查，不是实时挂载探测。因此，持续 Terminating 的声明需要检查已调度消费者、控制器进度和其他 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。
Persistent Volumes (v1.34)，v1.34 预绑定、访问模式边界与受支持的回收行为，已核验 2026-10-18。
PVC protection implementation，v1.34.0 podUsesPVC 的节点分配及显式引用检查，已核验 2026-10-18。

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

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

NFS 导出把服务器文件系统路径与客户端及访问策略关联起来。在 Linux 上，exportfs 根据 /etc/exports、/etc/exports.d 下合格文件或命令行更新，维护 /var/lib/nfs/etab。rpc.mountd 是守护进程，不是第三份配置文件；其 MOUNT 服务与旧版协议流程有关，NFSv4 挂载并不要求这个独立服务。应先明确版本和服务职责，再解释客户端的结果。

配置文本可能与有效导出不同，但这只是拒绝访问的一种原因，不能从文件看起来正确就断定导出表过期。还要核对目标服务器、协议、导出策略、身份及文件权限。服务器的持久性和客户端缓存也要分开：应用看到一次写入成功，并不单独证明服务器已把相应数据提交到稳定存储。目录可见、访问获准和写入可恢复，是不同层次的事实。

文件与表

/etc/exports 的条目把目录与客户端及选项关联。/srv/data 10.0.0.0/24(rw,sync,no_subtree_check,root_squash) 展示一个网络，后面还能追加有自己选项的客户端组。主机名、网段和 netgroup 有各自匹配规则。exportfs -ra 会协调配置与导出，但其他 exportfs 操作或服务管理也能应用改变；它不是唯一生效途径，不能把所有差异都归因于忘记运行这一条。

showmount -e 向服务器 MNT 服务询问公布的导出。信息完整性取决于实现，只有 NFSv4 的服务器甚至可能不暴露此服务。因此它既不是完整有效策略转储，也不证明某客户端一定能访问共享。原文四条配置对三条导出以及 NOENT 的故事没有找回原始运行记录；缺失导出也不能保证所有客户端总收到同一个错误码。诊断应保留实际返回信息。

选项真正决定了什么

导出默认只读，rw 才允许写入，但文件权限及其他控制仍然生效。sync 约束服务器按稳定存储要求回复，async 则允许改动提交前回复，崩溃可能丢失已确认的数据。两者都不会消除客户端缓存，也不让每次应用写入自动变成同步持久提交。nfs-utils 在 1.0.0 版本之后把默认从 async 改为 sync；理解版本历史时要与实际客户端操作分开。

root_squash 把请求中的零 uid/gid 映射到匿名身份，no_root_squash 关闭该保护。all_squash 映射全部身份，anonuid/anongid 指定匿名值。这些选项不是客户端认证，也不能让任意公开共享自动安全。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 则可能返回 EIO 并带来数据损坏风险。挂载选项本身不能保证某次进程一定处于指定状态。

在 AUTH_SYS 下，数字请求身份参与权限检查；服务器找不到某个非零 ID 对应的账户名字，不会自动把它匿名化。NFSv4 属主名字映射和更强认证又引入其他身份边界。应结合 id、ls -ln、squash 策略及映射配置检查。显示为 65534 或 nobody，可能来自有意匿名映射，也可能是映射失败，所以它是需要调查的现象，不是单一原因的证明。

坏掉的样子

导出确实过期时，需要核对包含 /etc/exports.d 及命令行覆盖的预期配置，再协调并检查结果。exportfs -ra 会改变服务器策略，也可能影响已有访问，执行前须审核。配置不一致与名称解析、网络可达、协议支持或权限失败不同，不能因为一个客户端操作失败就直接刷新策略。还应记录变更后的有效结果，而不只是保留编辑过的文件。

服务器不可用会让操作等待，严重影响应用，却不能因此断言所有碰到 hard 挂载的进程永久无法终止。原文三十五秒 showmount 失败在此没有原始证据，它也不能代表内核挂载客户端的超时行为。intr 在 Linux 2.6.25 之后被忽略；改为 soft 必须权衡数据完整性，不能只是为了让等待更短，就把潜在读写错误当作已经修复服务。

NFS 访问须经过策略：机制图。

快速验证

以下原命令保持不变并暂缓执行。它们混合了服务器检查、对 localhost 的 MNT 查询、策略修改以及客户端观察，却没有分别绑定主机。本轮没有操作 NFS 服务、发送 RPC、刷新导出或执行挂载；这段内容也不能作为实际读写或恢复通过的证据：

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

应比较策略，而不是打印出来的选项顺序。下面的离线提案只支持一条 /srv/data IPv4 网段导出，采用 nfs-utils 自 1.1.0 起的文档默认值。它展开省略的默认项，拒绝冲突、重复和未知选项，并比较原样路径与规范化网段。主机名、netgroup、通配符、多种安全机制及额外记录均不支持，不能静默当成等价。

import ipaddress
import re

# A single-export, numeric IPv4-network fixture; not a general exports parser.
def export_policy(text):
 match = re.fullmatch(
 r"(/srv/data)[ \t\n]+([0-9./]+)\(([^()\s]+)\)\n", text)
 if match is None or "/" not in match[2]:
 raise ValueError("incomplete or unsupported export record")
 client = ipaddress.IPv4Network(match[2], strict=True)
 mask = match[2].split("/")[1]
 if mask not in (str(client.prefixlen), str(client.netmask)):
 raise ValueError("noncanonical prefix or unsupported hostmask")
 groups = [
 ("ro", "rw"), ("sync", "async"), ("wdelay", "no_wdelay"),
 ("hide", "nohide"), ("no_subtree_check", "subtree_check"),
 ("secure", "insecure"), ("root_squash", "no_root_squash"),
 ("no_all_squash", "all_squash")]
 defaults = {group[0]: group[0] for group in groups}
 defaults.update(sec="sys", anonuid=65534, anongid=65534)
 owner = {token: group[0] for group in groups for token in group}
 seen = set()
 for token in match[3].split(","):
 if token in owner:
 name, value = owner[token], token
 elif token == "sec=sys":
 name, value = "sec", "sys"
 elif re.fullmatch(r"anon(?:uid|gid)=[0-9]+", token):
 name, raw = token.split("=")
 value = int(raw)
 if not 0 <= value < 2**32 - 1:
 raise ValueError("unsupported anonymous ID")
 else:
 raise ValueError(f"unsupported option: {token}")
 if name in seen:
 raise ValueError(f"duplicate or conflicting option: {name}")
 seen.add(name)
 defaults[name] = value
 return match[1], str(client), defaults

def compare_exports(configured, effective, *, complete, returncode, stderr):
 if (complete is not True or type(returncode) is not int or returncode != 0
 or type(stderr) is not str or stderr != ""):
 raise ValueError("failed, partial or unverified capture")
 if export_policy(configured) != export_policy(effective):
 raise ValueError("export path, client network or policy differs")

# Fabricated complete inputs exercise comparison only; no NFS command runs.
configured = "/srv/data 10.0.0.0/24(rw,sync,no_subtree_check,root_squash)\n"
effective = ("/srv/data\n\t10.0.0.0/255.255.255.0"
 "(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,"
 "root_squash,no_all_squash)\n")
compare_exports(configured, effective, complete=True, returncode=0, stderr="")
print("synthetic policy comparison passed; live NFS remains untested")

预期只输出合成策略比较通过的消息。若要建立真实证据，必须取得同一明确服务器上的完整成功采集，覆盖所有配置输入和预期命令行覆盖；不能根据过滤后的输出自行声称完整。其他配置须单独审阅。本轮没有采集、RPC、挂载或访问测试；本机发现和属主列表也不能证明访问权限。完整授权实验仍需明确服务器与客户端、按协议检查，并单独批准策略修改；此比较提案不因此获得真实 NFS 执行通过。

来源

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 与启用 AOF 恢复不同的精确值。AOF 使用自身文件集合；本轮没有新增运行，也不证明断电可恢复。

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

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

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

AOF 改变恢复数据的表示

AOF 记录数据变更，并按 appendfsync 策略同步。everysec 通常暴露大约最近一秒的写入，这并非严格的丢失上限；no 把刷盘时机交给操作系统。always 通常先同步再回复，代价是额外的同步开销。若设置 no-appendfsync-on-rewrite yes，Redis 会在 BGSAVE 或 BGREWRITEAOF 期间跳过主进程的 AOF fsync，使 always 和 everysec 的持久性都减弱。固定版本的配置默认将此例外设为 no。这些策略不保护整块存储设备丢失，也不能保证故障切换时被提升的副本包含每一条已经在原节点落盘的写入。

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

坏掉的样子

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

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

UNLOGGED 重启边界：机制图。

快速验证

把 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。
PostgreSQL 18 table commands source，第十八版分支的外键持久性限制，已核验 2026-10-18。
PostgreSQL 18 planner catalog source，恢复期间禁止访问 unlogged 关系，已核验 2026-10-18。

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

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 返回的旧值，就可能把同一位置分给两个人。同样，合并两天的活跃位图，前提是两份数据使用完全相同的编号映射，否则并集结果即使数值正常，也不再代表同一组用户。

置位数量与分配跨度不同。原文远端写零占一 MiB 载荷。BIT 位区间要求 Redis 7.0+；BITOP 结果须明确配置寿命。

快速验证

原有实验记录使用 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 不会暴露半个上传对象。请求失败或结果不明时，应确认实际状态，不能直接推断新版本被截断。单个对象的原子替换也无法防止丢失更新：两个客户端可能读取同一旧值，再分别覆盖它。条件请求可以在接受更新之前比较校验标识，但要遵循服务文档中的条件语义。模型的整数代数是虚构规则；S3 If-Match 使用 ETag，不是这个计数器，也不是版本 ID。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 或节点本地的软件暂存队列，以及硬件派发队列。请求可以在派发前经过调度和合并，但驱动与设备行为也会影响实际服务。软件提交顺序不保证完成顺序。调度器能够影响竞争请求进入设备的方式，却不控制整个存储栈后续的每一项决定。分析时应分别记录提交、派发与完成，避免从一条队列箭头推出设备执行的完整时间线。

在旋转介质上，改善请求局部性可以减少磁头移动。闪存没有机械寻道成本，但合并、并行度、排队和仲裁仍会影响性能。高效排序与公平服务回答不同问题，都不能给出普遍适用的调度器排名。应先确认当前内核与设备实际提供哪些选项，再测量相关负载，不要因为设备名称包含 NVMe 就把所有队列政策的成本与收益都当成零。

磁头才是预算

7200 RPM 下半圈约为 4.17 ms，可作为理想化的平均旋转等待。传输与寻道成本还依赖设备和负载。原文给出 2000 个请求、67907411 与 99977 条磁道，以及 91 与 231 IOPS，但没有提供生成夹具或保留测量。这些数字只能作为未经核验的原文声称，不能写成已经测得的 Linux 调度器结果，更不能用倍数直接推算生产设备的容量。

对一组虚构磁道位置排序，可以说明磁头行程有可能缩短，但没有经过验证的设备模型或测量，就不能建立 IOPS 收益。此前的寻道百分比和约 40 ms 的 NVMe 总耗时，也有同样的证据缺口。图中更短的路径因此只表示定性关系，不是延迟预测。实际比较应保留请求序列、模型假设、设备信息与原始输出，才能判断差异是否来自调度。

每种调度器是干什么的

none 不增加调度器重排，但不承诺全局先到先完成。mq-deadline 结合扇区顺序和批次之间的到期检查，fifo_batch 限制每批数量；这些政策影响派发，并不保证端到端完成期限。kyber 通过限流尝试达到读取与同步写入的目标延迟，目标值不是每个请求都必然达标的证明。设备处理时间与后续排队仍然存在，不能把参数名当成业务延迟服务承诺。

bfq 提供按权重的服务分配和低延迟启发式，带宽或时间分配取决于配置与条件。空转可以帮助服务保证，却也可能降低内部有队列设备的吞吐，必须核对内核支持和实际设置。/sys/block//queue/scheduler 中带方括号的名称表示当前选项；修改它是运维动作，需要已授权的设备和可撤销测试方案。不能只看到一个名称，就推定持久设置、隔离效果或吞吐收益已经建立。

公平与排序是两个问题

90/10 的请求发出比例，不能直接建立服务份额或平均等待位置。原文的 0.099、1901 与 0.5 没有保留夹具作为依据。在持续有积压的简化模型里，相等权重可以说明分享概念，但真实结果还取决于需求、请求大小、优先级和调度设置。应分别比较收到的服务、应用延迟与请求到达数量，不能把不同分母下的比例当成同一个指标，更不能保证轻客户端永远取得一半吞吐。

无论哪种介质，都应在代表性竞争下测试延迟、吞吐和隔离。cgroup io.max 在达到配置的 BPS 或 IOPS 上限时延迟输入输出，允许短暂突发，并不要求先选 BFQ。权重控制则依赖启用的实现与配置；BFQ 使用 io.bfq.weight，而 io.weight 可以由 I/O 成本控制器实现。上限与相对份额是不同控制，不应把二者都描述成只有某个调度器重排之后才有效。

坏掉的样子

旋转设备使用 none 值得结合负载检查，但本身不证明存在缺陷。高利用率、低 IOPS 和高 await 可以有多种原因；await 包含排队和服务时间，接近百分之百的利用率对串行设备可能表示饱和，对并行设备则不充分反映性能极限。应先确认设备拓扑、请求模式和竞争工作，再归因于寻道。rotational 标志不是一次磁头跟踪，几个平均数也不能单独证明应该切换策略。

批量任务可能恶化交互请求的长尾，即使平均值看起来正常。调度政策或控制组上限可能有帮助，但任何一个名称都不能单独证明应用级保护成立。应在受控变化前后比较分位数与有效吞吐。空转、队列深度和设备内部调度会相互影响，旋转标志本身无法选择普遍正确的配置。平均队列长度还受并发和服务时间影响，不能把它上升直接解释成请求没有被合并成一次扫描。

队列排序、权重服务与 io.max 上限不同；原文数值声称仍未经核验。

快速验证

首先用下面尚未执行的只读步骤观察一个明确选定的整盘设备。设置 DEVICE 前应核对拓扑与范围，不能根据名称随便选择生产设备。代码拒绝类似路径的名称，检查必需属性是否可读，并说明可选参数缺失；这第一个代码块不改变调度器。此处没有为切换策略或修改其他内核设置提供授权，也没有把已存在的运行限制当成静态修改后自动解除。

(
 : "${DEVICE:?Set DEVICE to the reviewed whole-device name}"
 case "$DEVICE" in
 ''|[!A-Za-z]*|*[!A-Za-z0-9_-]*|ALL) printf 'Invalid device name\n' >&2; exit 2 ;;
 esac
 queue="/sys/block/$DEVICE/queue"
 [ -d "$queue" ] || { printf 'No such whole-device queue\n' >&2; exit 1; }
 for field in rotational scheduler; do
 [ -r "$queue/$field" ] || { printf 'Missing: %s\n' "$field" >&2; exit 1; }
 value=$(cat "$queue/$field") || exit 1
 printf '%s=%s\n' "$field" "$value"
 done
 for field in read_expire fifo_batch; do
 if [ -r "$queue/iosched/$field" ]; then
 value=$(cat "$queue/iosched/$field") || exit 1
 printf '%s=%s\n' "$field" "$value"
 else
 printf '%s: unavailable for the active scheduler\n' "$field"
 fi
 done
 LC_ALL=C iostat -x -y -t "$DEVICE" 2 5
)

带方括号的名称是当前选项，缺少 iosched 参数可能正常。-y 排除开机统计，要保留错误并确认输出确实包含所选设备。路径检查不能替代拓扑审阅。

将辅助程序保存为 scheduler_exercise.py。它只适用于明确授权、由你独占控制的可丢弃测试设备。根据上面的观察设置 EXPECTED_CURRENT 与 REQUESTED，并把 ACK_DEVICE 设成 DISPOSABLE: 后接 DEVICE。需要 Python 3.9 以上、调度器写入权限和 sysstat；此步骤会临时改变策略，不能在生产或共享设备上照抄：

"""Unexecuted proposal: temporary policy change on an exclusively controlled test device."""
import json
import re
import signal
import subprocess
import sys
from pathlib import Path


def device_name(value):
 if not re.fullmatch(r"[A-Za-z][A-Za-z0-9_-]*", value) or value == "ALL":
 raise ValueError("use one named whole device, not a path, option, number or ALL")
 return value


def scheduler_state(path):
 tokens = path.read_text().split()
 active = [s[1:-1] for s in tokens if re.fullmatch(r"\[[A-Za-z0-9_-]+\]", s)]
 if len(active) != 1 or not tokens:
 raise ValueError("scheduler state must have exactly one bracketed choice")
 if any(not re.fullmatch(r"(?:[A-Za-z0-9_-]+|\[[A-Za-z0-9_-]+\])", s) for s in tokens):
 raise ValueError("unexpected scheduler state")
 available = [s.strip("[]") for s in tokens]
 if len(set(available)) != len(available):
 raise ValueError("duplicate scheduler choices")
 return active[0], available


def exercise(path, device, expected, requested, run=subprocess.run, emit=print):
 original, available = scheduler_state(path)
 if original != expected or requested not in available or requested == original:
 raise ValueError("current/requested scheduler does not match the reviewed plan")
 emit(json.dumps({"device": device, "original": original, "requested": requested}), flush=True)
 primary_error = restore_error = None
 attempted = False
 try:
 if scheduler_state(path) != (original, available):
 raise ValueError("scheduler state changed before the test")
 attempted = True # even a failed write may have changed state
 path.write_text(requested + "\n")
 if scheduler_state(path)[0] != requested:
 raise RuntimeError("requested scheduler was not activated")
 result = run(["iostat", "-x", "-y", "-t", device, "2", "5"], check=False)
 if result.returncode != 0:
 raise RuntimeError(f"iostat exited with status {result.returncode}")
 except BaseException as error:
 primary_error = f"{type(error).__name__}: {error}"
 finally:
 if attempted:
 try:
 if original not in scheduler_state(path)[1]:
 raise RuntimeError("original scheduler is no longer available")
 path.write_text(original + "\n")
 if scheduler_state(path)[0] != original:
 raise RuntimeError("original scheduler was not restored")
 except BaseException as error:
 restore_error = f"{type(error).__name__}: {error}"
 emit(json.dumps({"primary_error": primary_error, "restore_error": restore_error,
 "restored": attempted and restore_error is None}), flush=True)
 # Report both errors; restoration failure never hides the primary failure.
 return (1 if primary_error else 0) + (2 if restore_error else 0)


def main(args):
 if len(args) != 4:
 raise ValueError("usage: scheduler_exercise.py DEVICE EXPECTED_CURRENT REQUESTED DISPOSABLE:DEVICE")
 device, expected, requested, acknowledgement = args
 device = device_name(device)
 if acknowledgement != "DISPOSABLE:" + device:
 raise ValueError("explicit disposable-device acknowledgement required")
 path = Path("/sys/block") / device / "queue/scheduler"
 return exercise(path, device, expected, requested)


if __name__ == "__main__":
 def interrupted(number, frame):
 raise InterruptedError(f"received signal {number}; attempting restoration")
 signal.signal(signal.SIGINT, interrupted)
 signal.signal(signal.SIGTERM, interrupted)
 try:
 sys.exit(main(sys.argv[1:]))
 except (OSError, ValueError) as error:
 sys.exit(f"Scheduler test refused: {error}")

python3 scheduler_exercise.py "${DEVICE:?}" "${EXPECTED_CURRENT:?}" \
 "${REQUESTED:?}" "${ACK_DEVICE:?}"

程序记录原值、验证切换、采集间隔，再单独恢复并验证原值。退出状态 0 表示成功，1 表示主流程失败，2 表示恢复失败，3 表示二者都失败；JSON 分别保留两类错误，不能用恢复失败掩盖原错误，也不能忽略恢复错误。SIGINT/SIGTERM 会触发清理尝试，但 SIGKILL、重复中断或主机故障仍可能阻止恢复，应保留原值以便人工处理。这是可逆策略练习，不是性能或公平性证据；历史数值与实际运行仍待核验。

来源

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。
Linux deadline tunables，修订依据，已核验 2026-10-18。
Linux cgroup v2 I/O controls，修订依据，已核验 2026-10-18。
iostat manual，修订依据，已核验 2026-10-18。
sysstat upstream iostat manual，-y 略过开机统计，-t 标记间隔报告时间，已核验 2026-10-19。
Python signals，身份或受控操作的适用契约，已核验 2026-10-19。
sysstat iostat option parser，身份或受控操作的适用契约，已核验 2026-10-19。

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

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

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

坏掉的样子

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

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

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

解除槽的要求、旧文件名消失与追赶路径丢失是不同结果。该 PostgreSQL 流程仍待运行验证。

快速验证

在 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 的标准取回统一当成免费。二零二六年十月十八日核对的价目表列明 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。访问频率与恢复请求频率有关，却不是同一个数。

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

S3 先看访问，再算成本：机制图。

快速验证

用 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 映射陷阱

坏掉的样子

快速验证

来源