文件系统 · XB 现场笔记

扩展属性属于 inode，也受命名空间约束

Tue, 14 Dec 2027 00:00:00 +0000

扩展属性在普通文件内容流之外，为文件系统对象附加有名字的字节值。应用可以使用 user 命名空间存放小型元数据，其他命名空间则具有内核、安全模块或特权相关语义。它是否可靠，取决于文件系统、访问规则和传输工具。只有工作流程按明确契约保留并解释标签，元数据才能成为下游判断的有效依据。

坏掉的样子

属性值不一定是文本，可以包含空字符或任意二进制数据。把它当作以零结尾的字符串，或者假定固定编码，可能破坏原值。空属性和缺失属性也不是同一状态；如果都返回空字符串，就会隐藏元数据到底被刻意设为空，还是在传输中丢失。使用前需要明确编码与缺失语义，而不是依赖显示工具碰巧如何呈现。

同一文件系统内重命名保留对象及属性，复制内容通常却创建另一个 inode。复制工具决定尝试保留哪些元数据，因此文件哈希相同不能证明扩展属性相同。流程可能成功传递每一个内容字节，却遗漏下游需要的分类、来源或应用版本标签。内容校验通过，只能证明它实际覆盖的内容范围。

命名空间名称不会自动建立应用授权规则。设置 user.classification 为 private，不会让本来可读的文件变得保密。user 属性服从适用的文件访问权限，安全属性则有另外的文档语义与策略。把应用标签当作已经强制执行的访问控制，可能在标签看起来完好的同时暴露内容，因此需要检查实际读写行为。

快速验证

把脚本保存为 xattrs.py，在临时目录支持用户扩展属性的一次性 Linux 容器中，以 root 运行 python3 xattrs.py。实测使用 Linux 6.12.76、Python 3.11.2 和 ext4 卷。root 只用于切换到第二个普通数字身份做权限探针。请使用隔离的一次性机器或容器，不要为了这个演示给共享宿主增加权限；脚本不会创建账号：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os,shutil,subprocess,sys

def fails(code,operation):
 try:operation()
 except OSError as error:assert error.errno==code,error
 else:raise AssertionError('expected attribute error')
with TemporaryDirectory(prefix='xbcatm-xattr-') as directory:
 root=Path(directory);root.chmod(0o755);path=root/'data';path.write_bytes(b'public fixture');path.chmod(0o644)
 os.setxattr(path,'user.review',b'binary\0value\xff',os.XATTR_CREATE)
 assert os.getxattr(path,'user.review')==b'binary\0value\xff'
 fails(errno.EEXIST,lambda:os.setxattr(path,'user.review',b'other',os.XATTR_CREATE))
 fails(errno.ENODATA,lambda:os.setxattr(path,'user.missing',b'value',os.XATTR_REPLACE))
 os.setxattr(path,'user.empty',b'');assert os.getxattr(path,'user.empty')==b''
 os.removexattr(path,'user.empty');fails(errno.ENODATA,lambda:os.getxattr(path,'user.empty'))
 print('attribute values are bytes; empty differs from missing; CREATE and REPLACE enforce their preconditions')
 alias=root/'alias';os.link(path,alias)
 os.setxattr(alias,'user.review',b'shared',os.XATTR_REPLACE)
 assert os.getxattr(path,'user.review')==b'shared'
 moved=root/'moved';path.rename(moved);assert os.getxattr(moved,'user.review')==b'shared'
 plain=root/'plain';preserved=root/'preserved';shutil.copyfile(moved,plain);shutil.copy2(moved,preserved)
 fails(errno.ENODATA,lambda:os.getxattr(plain,'user.review'))
 assert os.getxattr(preserved,'user.review')==b'shared'
 assert plain.read_bytes()==preserved.read_bytes()==moved.read_bytes()
 print('hard links and same-filesystem rename retain inode attributes; copyfile omits them, copy2 preserves this supported user attribute')
 os.setxattr(moved,'user.classification',b'private')
 probe=r'''
from pathlib import Path
import errno,os,sys
path=Path(sys.argv[1]);assert path.read_bytes()==b'public fixture'
assert os.getxattr(path,'user.classification')==b'private'
try:os.setxattr(path,'user.classification',b'changed')
except OSError as error:assert error.errno==errno.EACCES
else:raise AssertionError('another identity changed a read-only user attribute')
'''
 result=subprocess.run([sys.executable,'-c',probe,str(moved)],user=61001,group=61001,extra_groups=[],capture_output=True,text=True,timeout=5)
 assert result.returncode==0,result.stderr
 fails(errno.E2BIG,lambda:os.setxattr(moved,'user.too_large',b'x'*65537))
 print('a user.classification label does not enforce confidentiality; file permissions block the other identity from changing it; oversized value returns E2BIG')

样本保存同时包含空字符和非 UTF-8 字节的值，并取回完全相同的字节。用 XATTR_CREATE 再次创建相同键，得到 EEXIST；用 XATTR_REPLACE 修改缺失键，得到 ENODATA。这些标志明确表达前提，而不是把所有写入都变成不检查原状态的覆盖。错误结果也是契约的一部分，需要由调用方实际处理。

显式空值读取后得到空字节，删除该键后再读则得到 ENODATA，直接区分缺失与有意为空。如果应用依赖元数据决定行为，应明确两种状态分别意味着什么，而不能为了接口方便，把它们都变成同一个默认值。否则属性传输失败可能在整个流程中完全不可见。

硬链接共享同一 inode，因此通过另一名字更新属性，会改变原名字看到的值。同一文件系统内重命名原路径，属性仍保留。随后分别复制文件：copyfile 保留内容但不带该用户属性，copy2 则在实测环境中保留它。这样把对象身份保持与新建对象复制，放在同一组具体结果中区分开。

三份内容流完全一致，元数据却有差异。Python 文档说明元数据复制取决于平台支持和权限，因此这次 copy2 成功，不保证所有命名空间和目标端都成立。应在实际传输后检查真正需要的属性，而不是仅凭复制命令返回成功，就推断原对象的所有语义都已随字节一起到达。

文件被标记为 private 时，模式仍为 0644。另一个普通身份成功读取内容和标签，证明标签没有实施保密；它因为缺少相应写权限，无法改动该属性。最后，超过六万五千五百三十六字节的值被 E2BIG 拒绝，展示实际大小边界。这些检查分别覆盖标签意义、访问控制和容量，而不是把它们混成一个状态。

在整个流程中保留含义

应选择带应用区分的键名，减少共享 user 命名空间里的碰撞，并定义值编码和版本。值要适合目标文件系统的限制；实际可用上限可能比 Linux 接口上限更小，还可能受 inode 上其他元数据影响。不能因为某个键在开发环境能写入，就假定任意目标存储具有相同容量和命名空间能力。

备份、归档、恢复和跨文件系统复制，都应同时检查内容与所需属性。有些目标不支持相关命名空间，有些工具只有启用特定选项才保留属性。元数据丢失究竟应使流程失败，还是允许采用有文档约定的替代表示，应由真实契约决定。需要保留什么，就必须在验证中实际检查什么。

更新文件字节和更新独立属性，并不会自动形成一笔应用事务。后续写入可能让校验标签过期，能够同时改动数据与标签的写者，也不是独立完整性权威。消费时应验证两者关系；如果需要在并发修改或不可信写者面前维持保证，就应选择具有相应能力的存储或签名契约，而不能只依靠一个看起来正确的标签。

来源

xattr(7)，属性命名空间、权限规则与存储限制，已核验 2026-09-12。
setxattr(2)，CREATE/REPLACE 行为与属性错误条件，已核验 2026-09-12。
getxattr(2)，二进制值与属性缺失错误，已核验 2026-09-12。
Python 3.11 shutil documentation，copyfile 与 copy2 尽力保留元数据的行为，已核验 2026-09-12。

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。

inotify 报告变化，但不是完整历史记录

Wed, 13 Oct 2027 00:00:00 +0000

inotify 通过一个带注册监视项和可读事件队列的实例，投递 Linux 文件系统通知。每条记录包含监视编号、事件掩码，也可能包含名字和移动 cookie。这能减少对未变化路径的反复检查，但事件流不是无限审计日志。正确消费者应把通知理解为相关状态可能需要重新检查的证据，而不能默认它保存了文件发生过的每一次操作。

坏掉的样子

监视目录不会递归监视后代。它报告直接目录项上的相关活动，因此需要观察更深变化时，新子目录也需要独立监视。目录树监视器必须处理初次枚举和之后加入的目录。假定只注册根目录就覆盖整棵树，会悄悄漏掉更深层变化；能收到子目录被创建，并不代表能收到它内部之后的全部操作。

文件监视跟随具体对象，不会永久绑定路径。编辑器可以先写完并关闭临时文件，再用 rename 替换目标。父目录会报告替换，旧文件监视却不会转移到新 inode。如果消费者等待目标名字之后再出现 close-write，可能永远等不到，因为替代文件在发布前已经关闭。不能把一种编辑器保存顺序当成所有更新方式的固定流程。

连续产生且尚未读取的相同事件可以合并，队列满后会丢弃事件并报告 IN_Q_OVERFLOW。因此，事件数量不是可靠写入计数。溢出后，消费者无法仅靠剩余记录重建全部缺失操作，必须重新核对当前监视状态，不能继续假定根据事件维护的模型完整。历史丢失与当前状态仍可读取，是需要分别理解的两件事。

快速验证

把脚本保存为 inotify-events.py，在一次性 Linux 环境中运行 python3 inotify-events.py。此前记录使用 Linux 6.12.76 和 ext4；本轮在 Linux 6.18.44、Python 3.12.14 环境重跑了两种语言的样本。样本创建 ASCII 名称的临时条目，并有意填满自己的队列。配置的队列上限必须不超过三万二千七百六十八；脚本只读取上限，不修改任何 sysctl：

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

MODIFY=0x2;ATTRIB=0x4;CLOSE_WRITE=0x8;MOVED_FROM=0x40;MOVED_TO=0x80
CREATE=0x100;DELETE=0x200;DELETE_SELF=0x400;MOVE_SELF=0x800;OVERFLOW=0x4000;IGNORED=0x8000
libc=ctypes.CDLL(None,use_errno=True)
libc.inotify_init1.argtypes=[ctypes.c_int];libc.inotify_init1.restype=ctypes.c_int
libc.inotify_add_watch.argtypes=[ctypes.c_int,ctypes.c_char_p,ctypes.c_uint32];libc.inotify_add_watch.restype=ctypes.c_int
header=struct.Struct('iIII')
with TemporaryDirectory(prefix='xbcatm-inotify-') as directory:
 root=Path(directory);fd=libc.inotify_init1(os.O_NONBLOCK|os.O_CLOEXEC);assert fd>=0,os.strerror(ctypes.get_errno())
 def watch(path,mask):
 wd=libc.inotify_add_watch(fd,os.fsencode(path),mask);assert wd>=0,os.strerror(ctypes.get_errno());return wd
 def drain():
 events=[]
 while True:
 try:data=os.read(fd,65536)
 except BlockingIOError:return events
 offset=0
 while offset<len(data):
 wd,mask,cookie,length=header.unpack_from(data,offset);offset+=header.size
 name=data[offset:offset+length].split(b'\0',1)[0].decode();offset+=length
 events.append((wd,mask,cookie,name))
 try:
 parent=watch(root,MODIFY|CLOSE_WRITE|CREATE|DELETE|MOVED_FROM|MOVED_TO)
 sub=root/'sub';sub.mkdir();drain();(sub/'unwatched').touch();assert drain()==[]
 nested=watch(sub,CREATE);(sub/'watched').touch();assert any(wd==nested and mask&CREATE and name=='watched' for wd,mask,_,name in drain())
 print('a directory watch is not recursive; adding a child-directory watch observes its new entries')
 counter=root/'counter';stream=os.open(counter,os.O_CREAT|os.O_WRONLY,0o600);drain()
 try:
 for _ in range(3):os.write(stream,b'x')
 finally:os.close(stream)
 events=drain();assert sum(wd==parent and bool(mask&MODIFY) and name=='counter' for wd,mask,_,name in events)==1
 moved=root/'moved';counter.rename(moved);events=drain()
 before=next(e for e in events if e[1]&MOVED_FROM and e[3]=='counter');after=next(e for e in events if e[1]&MOVED_TO and e[3]=='moved')
 assert before[2]==after[2]!=0
 print('three unread identical modifications coalesce; rename FROM/TO events share a nonzero cookie')
 target=root/'target';target.write_bytes(b'old');file_watch=watch(target,MODIFY|ATTRIB|DELETE_SELF|MOVE_SELF);drain()
 replacement=root/'replacement';replacement.write_bytes(b'new');drain();replacement.replace(target);events=drain()
 assert any(wd==file_watch and mask&IGNORED for wd,mask,_,_ in events)
 assert any(wd==parent and mask&MOVED_TO and name=='target' for wd,mask,_,name in events)
 assert not any(wd==parent and mask&CLOSE_WRITE and name=='target' for wd,mask,_,name in events)
 target.write_bytes(b'newer');events=drain()
 assert any(wd==parent and mask&MODIFY and name=='target' for wd,mask,_,name in events)
 assert all(wd!=file_watch for wd,_,_,_ in events)
 print('replacement invalidates the old file watch; the parent-directory watch continues to observe the pathname')
 burst=root/'burst';burst.mkdir();drain();watch(burst,CREATE)
 limit=int(Path('/proc/sys/fs/inotify/max_queued_events').read_text());assert 0<limit<=32768,'use a disposable environment with a bounded queue limit'
 for number in range(limit+8):(burst/str(number)).touch()
 events=drain();assert any(wd==-1 and mask&OVERFLOW for wd,mask,_,_ in events)
 current=len(list(burst.iterdir()));assert current==limit+8
 print('actual queue overflow:',len(events),'events retained for',current,'creates; rescan sees the current entries')
 finally:os.close(fd)

第一组监视父目录，创建子目录，并读走父级事件。随后在子目录内部创建文件，不会向父监视项产生事件；显式增加子目录监视后，下一次创建才被看到。这在同一个 inotify 实例中区分直接目录项覆盖和递归监视，避免只检查注册调用成功就以为整棵树都已进入观察范围。

对同一文件连续写三次，期间不读取队列，最终只观察到一条对应 modify 事件。随后重命名该文件，得到 cookie 相同且非零的 FROM 与 TO 记录。前者证明合并，而非每次写入都有独立通知；后者帮助关联这两条移动记录，却不是文件整个后续生命周期的持久身份，不能把它当作不会变化的对象编号。

接着监视一个文件，再用已经写完并关闭的文件替换其路径。旧对象被删除时，原监视项收到 ignored；父目录监视收到目标名字的 MOVED_TO，这次发布没有伴随目标 close-write。之后写入替代文件，父目录监视能看到，已经移除的旧文件监视不能。这正好验证路径替换时两种监视范围的不同结果。

溢出实验在队列上限一万六千三百八十四时，创建一万六千三百九十二个不同条目。得到一万六千三百八十五条记录，其中包含监视编号为负一的溢出通知；重新扫描目录，则找到全部当前条目。这同时展示缺失的事件历史，以及恢复当前状态知识的实际方法，不能把两者混称为完整历史恢复。

全部监视都属于一个由样本拥有的实例，清理临时目录树前会先关闭它。实验没有制造系统级监视项短缺，也没有修改其他应用队列。有界突发验证了真实溢出行为，不需要让应用长期过载，更没有把从未观察到的丢失信号当成已经验证。环境前提不满足时会明确失败。

协调路径和对象寿命

两侧移动都可见时，可以按 cookie 配对，但要处理移入、移出观察集合，以及中间穿插其他记录的情况。行动前还应检查相关路径。事件里的名字描述被报告的变化，不保证消费者稍后打开时，那里仍然是同一对象。通知与读取之间的变化窗口，需要由应用当前状态校验来处理。

监视目录树时，应在建立监视与核对目录内容之间考虑枚举期间发生的活动。溢出后，要从文件系统重建受影响状态，并恢复必要的监视覆盖。溢出记录不会指定一个缺失文件名，因此不能按普通逐监视项事件处理它，也不能仅重读某个碰巧出现在队列末尾的路径就声称完整恢复。

适合由通知触发的工作，应能容忍重复或合并变化，例如校验当前内容后重新加载整份配置。如果每一次状态转换都必须保留，则需要应用日志或具有相应历史契约的接口。inotify 的价值建立在它的覆盖和丢失规则与需求相匹配，而不是把事件队列想象成不会漏项的永久记录。

来源

inotify(7)，事件格式、合并、溢出、重命名与非递归监视，已核验 2026-10-15。
inotify_add_watch(2)，监视注册与对象身份，已核验 2026-10-15。
Linux 6.12 inotify UAPI，可执行样本使用的事件结构和标志值，已核验 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。

硬链接共享 inode，替换名字后关系会改变

Sun, 10 Oct 2027 00:00:00 +0000

硬链接为已有文件增加另一个目录项。两个名字都指向同一文件系统里的同一个 inode，其中没有哪个天然具有“原件”地位。内容、所有者、权限和链接数属于这个共享对象，文件名只是到达它的入口。因此，需要把目录项的变化与文件对象本身的变化分开理解，才能判断修改、删除和替换到底影响了哪些访问路径。

坏掉的样子

把硬链接当成独立备份，会产生错误的恢复边界。通过任意名字写入或截断共享 inode，另一名字读到的内容也会改变；修改模式位，同样改变的是一个对象的权限。第二个路径可以在第一个路径被删除后继续存在，却不能抵御针对共享文件的普通原地修改，也不会自动保留先前历史版本。

许多编辑器和部署工具采用另一种更新方式：先创建替代文件，再通过 rename 覆盖某个路径。该目录项此时指向新 inode，其他硬链接仍然到达旧对象。两个名字是否一起显示新内容，取决于实际更新方法。因此不能仅凭它们昨天建立过硬链接，就断言今天仍共享身份；应检查当前对象以及写入工具的真实行为。

硬链接还受文件系统挂载边界约束。即使两个目录在统一路径树里看起来相邻，link 也不能随意把不同挂载中的对象连接起来。Linux 还禁止普通目录硬链接。这些限制意味着，硬链接不能作为跨目录层次、跨挂载符号链接的通用替代品；使用前必须先确认目标对象和边界，而不是只看路径字符串。

快速验证

把脚本保存为 hardlinks.py，在有权创建临时目录的 Linux 环境运行 python3 hardlinks.py。它要求 /tmp 与 /run 可写且属于不同文件系统；需要时可将 CROSS_ROOT 设为另一文件系统上的可写目录。实验不要求 root，也不创建挂载，并会明确检查跨文件系统前提。实测使用两个独立 tmpfs 挂载、Linux 6.12.76 和 Python 3.11.2，所有新建条目都位于临时目录中：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os

with TemporaryDirectory(prefix='xbcatm-hardlinks-',dir='/tmp') as directory, TemporaryDirectory(prefix='xbcatm-crosslink-',dir=os.environ.get('CROSS_ROOT','/run')) as other:
 root=Path(directory);source=root/'source';alias=root/'alias'
 source.write_bytes(b'original');os.link(source,alias)
 before=source.stat();linked=alias.stat()
 assert (before.st_dev,before.st_ino)==(linked.st_dev,linked.st_ino)
 assert before.st_nlink==linked.st_nlink==2 and before.st_size==linked.st_size==8
 alias.write_bytes(b'changed')
 assert source.read_bytes()==b'changed'
 print('two names share device/inode, size, and link count; in-place write changes both views')
 replacement=root/'replacement';replacement.write_bytes(b'new file');replacement.replace(source)
 assert source.stat().st_ino!=alias.stat().st_ino
 assert source.read_bytes()==b'new file' and alias.read_bytes()==b'changed'
 assert source.stat().st_nlink==alias.stat().st_nlink==1
 print('atomic replacement changes one name to a new inode; the other name retains the old file')
 with alias.open('rb') as opened:
 alias.unlink()
 assert os.fstat(opened.fileno()).st_nlink==0 and opened.read()==b'changed'
 print('last unlink removes the final name but an existing open descriptor still reads the old data')
 assert root.stat().st_dev!=Path(other).stat().st_dev,'exercise requires two filesystem mounts'
 try:os.link(source,Path(other)/'cross-filesystem')
 except OSError as error:assert error.errno==errno.EXDEV,error
 else:raise AssertionError('cross-filesystem hard link unexpectedly succeeded')
 child=root/'directory';child.mkdir()
 try:os.link(child,root/'directory-link')
 except OSError as error:assert error.errno==errno.EPERM,error
 else:raise AssertionError('directory hard link unexpectedly succeeded')
 print('cross-filesystem link fails with EXDEV; directory hard link fails with EPERM on Linux')

样本先创建 source，写入八字节内容，再通过 os.link 添加 alias。两个名字报告相同的设备与 inode 组合、八字节大小，以及值为二的链接数。比较时必须包含设备身份，因为 inode 编号并不跨文件系统全局唯一；仅仅比较内容相同，也无法证明两个入口共享对象，独立副本同样可能有相同字节。

通过 alias 写入 changed，会修改现有 inode，因此读取 source 得到相同新内容。这次操作是普通截断写入，没有替换路径。结果直接解释了为什么第二个名字不能作为保护旧内容的独立副本：只要写者能够修改共享对象，两条访问路径就一起看到变化，即使另一条路径从来没有被该写者直接打开。

随后，包含 new file 的独立文件通过 rename 替换 source。两个名字此时报告不同 inode，链接数分别变成一。source 读到替代文件，alias 则保留 changed。替换只改变选中的目录项，不会搜索旧 inode 的其他名字，更不会把所有硬链接统一改指向新对象。更新行为由对象身份决定，而不是由哪个名字被称作原件决定。

样本打开 alias，再删除它最后的目录项。通过已打开描述符读取状态，链接数为零，但仍能读到 changed。打开引用在关闭前继续保留访问能力。链接数为零，表示没有硬链接名字留下，并不表示每个进程都立即失去现有引用；因此路径消失与所有使用者结束，是需要分别观察的状态。

最后，向第二个文件系统建立硬链接得到 EXDEV，尝试硬链接目录得到 EPERM。脚本检查具体错误。如果两个临时根目录实际位于同一文件系统，前提检查会明确失败，不会假装已经验证跨文件系统限制。这样得到的失败证据对应真实边界，而不是依据目录名字推测挂载关系。

检查身份和实际更新方式

依赖共享存储之前，应检查目标路径当前的设备与 inode 组合及链接数。链接数说明有多少硬链接目录项指向对象，但不会列出这些名字位于哪里。遍历目录寻找匹配 inode 是另一个操作，会受访问权限和扫描期间变化影响。不能把一个计数当成完整路径清单，也不能忽略检查之后对象仍可能被替换。

如果使用硬链接构建类似快照的目录树，应确保更新采用替换文件方式，并控制所有能够触及共享 inode 的写者。文件系统快照与独立复制具有不同契约。节省空间的链接树，应按照真实更新方式和保留能力描述，而不能仅凭多个目录看起来各有一份文件，就声称已经建立独立备份。

unlink 和 rename 主要影响命名空间可见性。本实验验证身份与打开引用行为，没有验证断电后的持久性。如果发布结果必须可靠落盘，还应另外核对文件系统同步要求与应用恢复流程。多保留一个名字，或者观察到原子替换成功，都不足以单独证明预期数据能够经历崩溃并完整保留。

来源

link(2)，共享 inode 身份、跨文件系统限制与目录链接错误，已核验 2026-09-12。
unlink(2)，链接数减少与已取消链接文件的打开寿命，已核验 2026-09-12。
rename(2)，替换一个路径而不改变其他硬链接，已核验 2026-09-12。

符号链接保存路径，不永久绑定目标身份

Tue, 03 Aug 2027 00:00:00 +0000

符号链接是保存目标路径的文件系统对象。跟随链接时，系统按操作发生时的状态解析这段路径；链接并没有永久绑定目标 inode。这个区别解释了为什么符号链接可以跨文件系统、为什么会变成悬空链接，以及为什么保存的目标文本完全没变，最终访问对象却可能改变。理解链接对象与当前解析目标，是正确使用和诊断链接的基础。

坏掉的样子

相对目标以符号链接所在目录为基准，而不是以调用进程的当前工作目录为基准。因此移动链接可能改变其含义；移动或重命名目标，则可能让链接悬空。部署过程如果调整目录结构，却没有核对这些解析基准，熟悉的链接就可能悄悄访问另一个文件。仅看 readlink 打印的文本没有变化，无法证明对象仍相同。

不同存在性检查回答不同问题。跟随链接的操作可能报告目标缺失，而检查目录项本身的操作仍能找到链接。同样，宽松路径解析函数可以在最终目标不存在时返回绝对字符串。规范化后的路径不是可用文件当前存在的证明，更不是文件身份的永久凭据；诊断必须说明自己检查了链接对象，还是跟随之后的目标。

当其他参与者能够修改相关目录项时，先检查路径再打开，会留下检查与使用之间的时间窗口。给路径加引号可以保护 shell 参数解析，却不能冻结文件系统解析。普通 open 的 O_NOFOLLOW 拒绝最后一个组件是符号链接，不会自动禁止前面目录组件中的链接。把参数安全、路径安全和对象稳定性混为一谈，会造成错误边界。

快速验证

把脚本保存为 symlinks.py，在一次性 Linux 环境中运行 python3 symlinks.py。实测使用 Linux 6.12.76 和 Python 3.11.2。脚本创建无害临时文件，并主动改变自己的链接，因此结果是确定性的，不需要并发攻击者，也不访问无关路径：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os

def read_no_follow(path):
 fd=os.open(path,os.O_RDONLY|os.O_NOFOLLOW)
 try:return os.read(fd,100)
 finally:os.close(fd)
with TemporaryDirectory(prefix='xbcatm-symlinks-') as directory:
 root=Path(directory);first=root/'first';second=root/'second';first.mkdir();second.mkdir()
 (first/'data').write_text('first');(second/'data').write_text('second')
 link=first/'link';link.symlink_to('data')
 assert os.readlink(link)=='data' and link.read_text()=='first'
 assert link.lstat().st_ino!=link.stat().st_ino
 moved=second/'link';link.rename(moved)
 assert os.readlink(moved)=='data' and moved.read_text()=='second'
 print('moving a relative symlink changes its target because resolution starts at its containing directory')
 (second/'data').rename(second/'renamed')
 assert moved.is_symlink() and os.path.lexists(moved) and not moved.exists()
 assert moved.resolve(strict=False)==second/'data'
 try:moved.resolve(strict=True)
 except FileNotFoundError:pass
 else:raise AssertionError('strict resolution unexpectedly found missing target')
 moved.unlink();assert (second/'renamed').read_text()=='second'
 print('dangling link exists as a link; permissive resolution can name a missing target; unlink removes only the link')
 safe=root/'safe';outside=root/'outside';safe.write_bytes(b'approved');outside.write_bytes(b'replaced')
 current=root/'current';current.symlink_to('safe');checked=current.resolve(strict=True)
 assert checked==safe
 opened=os.open(current,os.O_RDONLY)
 try:
 replacement=root/'next';replacement.symlink_to('outside');replacement.replace(current)
 assert current.read_bytes()==b'replaced' and os.read(opened,100)==b'approved'
 finally:os.close(opened)
 print('a checked path string can resolve differently later; an already opened descriptor keeps the prior object')
 try:read_no_follow(current)
 except OSError as error:assert error.errno==errno.ELOOP,error
 else:raise AssertionError('O_NOFOLLOW accepted a final-component symlink')
 alias=root/'parent-alias';alias.symlink_to(first.name,target_is_directory=True)
 assert read_no_follow(alias/'data')==b'first'
 print('O_NOFOLLOW rejects the final symlink but still allows symlinks in earlier path components')

第一个目录中有名为 data 的文件，以及目标文本仅为 data 的链接。通过链接读取，得到 first。lstat 检查链接本身，stat 则跟随链接检查目标，样本确认两者具有不同 inode 身份。这两个结果用于说明它们确实是两个对象，而不是同一对象的两种显示名称。

把链接移到第二个目录后，readlink 仍然返回相同文本，但读取结果变成 second。此时目标是第二个目录里的 data 文件。实验没有通过改变进程工作目录解释结果，而是直接改变链接所在位置，因此明确展示相对路径解析基准。保留同一段目标文本，不意味着移动链接是没有语义变化的操作。

重命名第二个目标后，链接悬空。is_symlink 与 lexists 仍为真，跟随目标的 exists 则为假。Python 的宽松 resolve 返回预期但不存在的目标路径，严格模式抛出 FileNotFoundError。删除悬空链接后，已经重命名的目标仍然完好，因为 unlink 删除的是链接目录项，不会追着旧目标把它也删除。

随后，脚本把链接解析到无害的已认可文件，并打开它，再把链接替换为指向另一个样本文件的版本。新的路径读取返回 replaced，之前打开的描述符仍然返回 approved。先前检查没有约束后续查找；已有描述符则保留了先前对象。这个对照直接展示两个操作之间的对象选择差异，不依赖偶然碰上的竞争时序。

对最终链接使用 O_NOFOLLOW 打开，得到 ELOOP。但是用相同标志打开 parent-alias/data 时，如果 parent-alias 是目录符号链接，操作仍会成功。两个结果必须一起解释：只验证最后一段拒绝，很容易错误宣称该标志保护了整条路径，使所有中间目录中的链接都无法被跟随。

分别确定对象与遍历策略

问题涉及保存的链接文本时使用 readlink，涉及链接本身时使用 lstat，涉及当前目标时使用跟随操作，并记录诊断实际报告的是哪种身份。日志里的绝对解析路径有助于理解上下文，但仍然只是某一时刻的观察。之后目录项被替换时，这段字符串不会自动保留先前解析结果的对象关系。

如果操作必须限制在可信目录边界内，应围绕目录描述符及适合威胁模型的约束设计遍历。Linux 的 openat2 提供拒绝符号链接、限制在目录之下等解析策略，使用时需要核对精确语义和内核支持。单纯把可信前缀与外部输入拼接，并不能建立目录包含关系，更不能代替实际的内核解析约束。

打开描述符可以避免后续路径替换改变它引用的对象，却不会让对象内容不可修改，也不会证明最初打开已经获得授权。应验证选中的对象，并通过适当引用执行目标操作。路径选择保证、访问权限和内容一致性需要分别设计；把其中一项测试成功当成三项都成立，会留下实验并未覆盖的错误假设。

来源

symlink(7)，保存的目标字符串、相对解析与悬空链接，已核验 2026-09-12。
open(2)，O_NOFOLLOW 与路径变化后的描述符引用，已核验 2026-09-12。
path_resolution(7)，逐段路径遍历与目录权限，已核验 2026-09-12。
openat2(2)，由内核执行的受控路径解析约束，已核验 2026-09-12。

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。

只读根在其范围内限制文件系统修改

Wed, 23 Dec 2026 00:00:00 +0000

只读根文件系统限制对服务打包代码和配置所在文件系统层的普通写入，明确挂载仍可提供运行数据的可写位置。这能减少意外修改和部分持久化机会，但边界是文件系统变更本身。它不会单独移除进程权限、阻止读取可访问数据，也不会禁止与其他服务通信，需要按实际作用范围理解其价值。

坏掉的样子

应用经常在主要数据目录之外写入临时文件、缓存、锁文件、生成配置或运行状态。只读根会让这些假设在启动或不常见操作中以 EROFS 暴露。只测健康检查端点，可能漏掉生成报表、刷新缓存或关停清理时才经过的写入路径。因此必须沿真实工作流程检查需求，不能把进程成功启动当成全部功能可用。

即使容器根层只读，可写挂载仍然可写，其中状态仍可能被故障或受损进程改坏。把大块可写目录覆盖到打包路径，也可能抵消这些路径原本需要的保护。应检查最终挂载布局，而不是根据一个根层选项推断整棵路径树的行为。路径看起来位于只读根之下，并不证明中间没有另一个可写挂载。

只读与保密也是不同属性。进程仍可能读取打包文件、执行已有程序，并通过允许的网络路径发送数据。该设置也不保证容器逃逸之后仍受相同保护，更不约束能够改变挂载安排的权限。应结合凭据、能力、隔离和应用行为理解它的贡献，避免把一项文件系统限制描述成完整安全边界。

快速验证

在一次性 Linux 容器内以 root 运行下面 Python 脚本。容器应使用只读根，在 /tmp 挂可写 tmpfs，在 /work 挂独立可写卷，镜像内预先安装 Python 3。实测使用 Linux 6.12.76 和 Python 3.11.2，没有宿主机绑定挂载、特权模式或外部网络：

from pathlib import Path
from tempfile import TemporaryDirectory
import errno,os,socket,subprocess,sys,uuid

assert os.geteuid()==0,'run inside a disposable read-only-root container as root'
assert os.statvfs('/').f_flag&os.ST_RDONLY
name='xbcatm-readonly-'+uuid.uuid4().hex
for base in [Path('/'),Path('/usr'),Path('/etc')]:
 path=base/name
 try:fd=os.open(path,os.O_WRONLY|os.O_CREAT|os.O_EXCL,0o600)
 except OSError as error:assert error.errno==errno.EROFS,error
 else:
 os.close(fd);path.unlink();raise AssertionError('root filesystem accepted a new file')
print('even this root process receives EROFS on paths in the read-only root, usr and etc tree')
for base in ['/tmp','/work']:
 assert not os.statvfs(base).f_flag&os.ST_RDONLY
 with TemporaryDirectory(prefix='xbcatm-write-',dir=base) as directory:
 path=Path(directory)/'data';path.write_bytes(b'allowed');assert path.read_bytes()==b'allowed'
 path.write_bytes(b'changed');assert path.read_bytes()==b'changed'
print('explicit tmpfs and data-volume mounts remain writable, including overwriting their contents')
assert Path('/etc/os-release').read_text()
result=subprocess.run([sys.executable,'-c','print("executed")'],capture_output=True,text=True,check=True)
assert result.stdout.strip()=='executed'
with socket.socket() as listener,socket.socket() as client:
 listener.bind(('127.0.0.1',0));listener.listen(1);client.connect(listener.getsockname())
 connection,_=listener.accept()
 with connection:
 client.sendall(b'local');assert connection.recv(5)==b'local'
print('reading packaged files, executing an existing program, and loopback network I/O still work')

脚本先检查根文件系统报告的只读标志，再尝试在根、usr 和 etc 下排他创建唯一名字的文件。即使采用 root 身份，三次都得到 EROFS。唯一名称与排他创建保证探测不会覆盖既有配置文件。结果来自当前文件系统真正拒绝操作，而不是只看配置中出现了某个只读选项。

随后检查 tmp 与 work 不带相同只读标志，并在两处创建、读取和覆盖临时文件。这确认可写例外仍能工作，也说明这些位置的暴露面：根层设置不会保护特意可写的数据免受同一进程修改。正确部署既要验证拒绝了不需要的写入，也要验证真正需要的写入仍然可用。

读取 os-release 和执行已有 Python 解释器均成功，说明只读存储不同于禁止读取或执行的策略。保护打包文件免于被修改很有用，却不是对现有代码所能执行动作的全面限制。进程仍然拥有其他权限时，可以继续利用那些权限处理数据或启动程序，不能仅凭根层不可写就推断其行为范围。

最后，一个监听端与客户端通过回环交换无害数据。容器没有外部网络，但本地套接字仍然工作，展示文件系统选项本身不会关闭网络。这没有验证任何外部连通策略，也没有访问生产服务。实验把文件系统修改和通信操作分开观察，避免把一个设置误解为同时覆盖所有资源类型。

所有可写探测都位于会被清理的临时目录。样本验证当前挂载安排中的选定运行操作，没有因为根层探测失败，就声称已经覆盖应用所有路径，也没有假定未来新增可写挂载会自动受到相同限制。真实服务是否完整可用，仍应由其具体调用路径和异常流程验证。

分开打包文件、临时空间与持久状态

可写路径应来自观察到的应用需要，并让程序明确使用这些位置。例外范围要小到能够解释用途。出现失败时，应定位所需路径和生命周期，而不是为了一个意外缓存或临时文件，就重新开放整个根层。这样既能修复真实功能要求，也能保留原本需要的修改边界。

tmpfs 适合相应临时数据，同时要考虑内存使用和生命周期。Docker 提醒，这些内存页仍可能进入交换空间，因此“由内存支持”不保证敏感字节绝不会写到持久介质；临时存储选择不能直接代替保密要求。状态需要独立于容器可写层保留时，应使用单独管理的卷，并配套备份和恢复。可写卷提供存储位置，却不会自动建立崩溃持久性、保密性或已经验证的恢复流程。位置选择和数据保证是相关但不同的设计事项。

对于 systemd 管理的服务，ProtectSystem 与指定状态、运行目录等机制，可以表达相关限制，但各自具有文档规定的语义。应验证服务真实视图和身份，不能只按选项名字在平台之间机械翻译。启动、普通工作、异常操作和清理都应被覆盖，并确认禁止和必需的写入分别符合预期。

来源

Docker container run reference，只读根文件系统与单独挂载的可写路径，已核验 2026-09-12。
Docker tmpfs mounts，临时挂载存储及生命周期，已核验 2026-09-12。
Docker volumes，独立于容器根层的卷生命周期，已核验 2026-09-12。
systemd 252 execution environment，ProtectSystem 与明确可写的服务目录，已核验 2026-09-12。

文件锁保护共同协议中的特定对象

Sat, 05 Dec 2026 00:00:00 +0000

文件锁协调的是一组参与者：大家约定锁哪个对象、何时获取锁，以及哪些操作必须放在临界区内。Linux 提供多种锁接口，它们的所有权和释放规则并不相同。选一个文件名，再调用名称里带 lock 的函数，并不足以构成正确协议；还必须明确底层对象、锁的种类，以及相关每份引用的寿命，否则看起来都成功加锁的程序仍可能同时修改同一份逻辑数据。

坏掉的样子

在本实验使用的 Linux 本地文件系统上，flock 提供建议式互斥。另一个请求冲突锁的进程会等待或失败，但完全没有请求锁的普通写入仍然可以进行。因此，文件锁不会赋予内容隐私，也不会自动限制所有能够打开文件的程序。只有参与者实际遵循共同协议，互斥才能保护需要保持一致的数据操作。

如果更新通过新 inode 替换原路径，直接锁数据文件就会出现对象分离。已有锁仍关联旧的打开文件描述，后续打开者却访问替换后的文件，并可能成功获取另一把锁。两个写者都以为自己独占同一份逻辑文档，实际锁住的却是不同对象。路径名称稳定，并不意味着路径背后的文件身份稳定。

传统 POSIX 记录锁还具有容易忽略的寿命规则：锁属于进程，该进程关闭任何一个指向该文件的描述符，都会释放它在该文件上持有的记录锁。因此，某个库独立打开并关闭同一 inode，也可能使程序其他位置持有的锁失效。这与通过打开文件描述拥有锁的 flock 不同，不能把两套释放规则混用。还要注意，通过任意复制引用显式解锁，也会释放同一把 flock；其他复制描述符仍然打开，并不能抵消显式解锁。

快速验证

把脚本保存为 locking.py，在一次性 Linux 环境中运行 python3 locking.py。实测环境为 Linux 6.12.76、Python 3.11.2 和本地 tmpfs。每个竞争锁的请求都在独立子进程中执行，并使用非阻塞获取，因此预期冲突会产生可检查结果，不会让演示一直挂起：

from pathlib import Path
from tempfile import TemporaryDirectory
import fcntl,os,subprocess,sys

probe_code=r'''
import fcntl,sys
with open(sys.argv[1],'r+') as handle:
 try:
 if sys.argv[2]=='flock':fcntl.flock(handle,fcntl.LOCK_EX|fcntl.LOCK_NB)
 else:fcntl.lockf(handle,fcntl.LOCK_EX|fcntl.LOCK_NB,1,int(sys.argv[3]),0)
 except BlockingIOError:print('blocked')
 else:print('acquired')
'''
def probe(path,kind='flock',start=0):
 result=subprocess.run([sys.executable,'-c',probe_code,str(path),kind,str(start)],capture_output=True,text=True,timeout=5)
 assert result.returncode==0,result.stderr
 return result.stdout.strip()
with TemporaryDirectory(prefix='xbcatm-locks-') as directory:
 root=Path(directory);target=root/'data';target.write_text('original')
 handle=target.open('r+');fcntl.flock(handle,fcntl.LOCK_EX)
 assert probe(target)=='blocked'
 subprocess.run([sys.executable,'-c',"from pathlib import Path;import sys;Path(sys.argv[1]).write_text('uncooperative')",str(target)],capture_output=True,text=True,check=True)
 handle.seek(0);assert handle.read()=='uncooperative'
 duplicate=os.dup(handle.fileno());handle.close()
 try:assert probe(target)=='blocked'
 finally:os.close(duplicate)
 assert probe(target)=='acquired'
 print('flock blocks cooperating contenders but not ordinary writes; dup retains the same lock')
 with target.open('r+') as handle:
 fcntl.flock(handle,fcntl.LOCK_EX)
 replacement=root/'replacement';replacement.write_text('new inode');replacement.replace(target)
 assert os.fstat(handle.fileno()).st_ino!=target.stat().st_ino
 assert probe(target)=='acquired'
 lockfile=root/'stable.lock';lockfile.touch()
 with lockfile.open('r+') as handle:
 fcntl.flock(handle,fcntl.LOCK_EX)
 replacement.write_text('next inode');replacement.replace(target)
 assert probe(lockfile)=='blocked'
 assert probe(lockfile)=='acquired'
 print('replacing locked data changes the inode; a separate stable lock file protects that replacement protocol')
 first=os.open(target,os.O_RDWR);second=os.open(target,os.O_RDWR)
 try:
 fcntl.lockf(first,fcntl.LOCK_EX|fcntl.LOCK_NB,1,0,0)
 assert probe(target,'record',0)=='blocked' and probe(target,'record',1)=='acquired'
 os.close(second);second=None
 assert probe(target,'record',0)=='acquired'
 print('POSIX record locks permit disjoint bytes; closing another descriptor to the inode releases process-owned locks')
 finally:
 if second is not None:os.close(second)
 os.close(first)

首先，父进程持有排他 flock，遵守协议的子进程报告 blocked。另一个子进程完全不请求锁就写入文件，父进程随后读到修改后的内容。同一个文件、同一组权限下的两个结果，分别证明互斥确实存在，以及它的建议式边界。不能只展示一个竞争者失败，就推断所有普通读写也会被锁阻止。

父进程接着复制描述符，并关闭最初的包装对象。竞争者仍被阻止，因为复制引用继续指向带锁的打开文件描述。直到最后这份复制引用关闭，下一次竞争才成功。只统计包装对象，或者认为第一次 close 一定释放锁，都会误判真实寿命；资源管理必须追踪仍然存在的打开引用。

随后，父进程锁住数据文件，再用新文件原子替换其路径。描述符报告的 inode，与此时按路径查到的 inode 不同。子进程打开该路径，并成功获取自己的锁。原子替换保证名字在替换过程中可用，却不会把旧打开描述上的锁搬到新 inode；这正是“同名所以同锁”推理失效的地方。

下一组对照使用独立的 stable.lock。所有写者约定，先锁住这个稳定对象，再替换数据路径。竞争者在替换后仍被阻止，释放后才成功。此协议成立的前提是参与者保持锁文件身份稳定；如果运行中删除再创建锁文件，就可能重现原来不同进程锁住不同对象的问题，不能把独立文件名本身当作保证。

最后通过 lockf 验证传统 POSIX 记录锁。锁住第零个字节，会阻止请求相同字节的子进程，却允许另一个子进程锁第一个字节。父进程关闭第二份独立打开的描述符后，第零字节的锁被释放，最初用于加锁的描述符此时仍然打开。最终竞争成功，直接展示了进程级记录锁的关闭语义。

明确所有参与者遵守的协议

各参与者必须使用一致的锁种类和对象。在 Linux 本地文件系统上，传统记录锁与 flock 通常是相互独立的机制，混用不能建立互斥。NFS、SMB 可能采用不同模拟方式及交互规则；把本地结果用于远程存储前，应核对实际文件系统和挂载行为，不能从函数名字相同就推断所有语义相同。

锁范围要覆盖整条需要保持的约束。只有操作真正独立时，不同记录区间才允许安全并行；共享头部或索引可能要求更广协调。与关键数据无关的慢操作应放在临界区外，需要同时取得多把锁时使用一致顺序，避免彼此等待成环。范围越小并不自动越正确，关键在于完整覆盖更新关系。

正常返回、异常和描述符转移都要定义清理规则。进程终止会按所有权规则释放内核锁，但复制或继承的引用可能延长某些锁的寿命。锁也不会让写入自动持久化，更不会修复已完成一半的更新。因此互斥还应与文件格式所需的更新、恢复协议配合，分别验证并发一致性和失败后的数据状态。

来源

flock(2)，建议锁、打开文件描述与远程文件系统差异，已核验 2026-09-12。
fcntl_locking(2)，POSIX 记录锁范围与进程所有权释放规则，已核验 2026-09-12。
rename(2)，路径替换与既有打开引用的存续，已核验 2026-09-12。

让持久状态和临时空间拥有不同生命周期

Thu, 03 Dec 2026 00:00:00 +0000

持久应用状态和可丢弃临时文件，需要不同的保留、容量与恢复策略。分开路径有助于表达这些策略，但目录本身不会创造持久性，也不会隔离磁盘容量。真正决定进程重启、容器替换、宿主故障或清理后保留什么的，是路径背后的存储。可靠布局需要把每类数据连接到明确生命周期，而不是仅仅给文件夹起两个不同名字。

坏掉的样子

如果清理任务把混合目录全部当作可丢弃内容，可能在删除临时下载时一起删除已提交记录。相反，也可能备份了大量可重建缓存，却漏掉真正重要的小数据库。文件扩展名和年龄不能代替对应用所有权的理解；需要知道路径由谁管理，以及其内容是否真的能从权威来源重新构造，才能决定能否删除。

容器重启和替换也不同。停止再启动同一个容器，通常保留其可写文件系统层；删除容器才会丢弃该层，而明确保留的命名卷可以继续存在。tmpfs 又有不同生命周期，容器停止时其内容会消失。把这三类位置统称为临时，会掩盖影响恢复流程的区别，导致测试重启成功后就误以为替换也安全。

同一个文件系统里的两个目录，仍然竞争该文件系统的剩余空间。只把临时路径从 /data/tmp 改成 /scratch，却不改变存储策略，并不会自动保护数据库写入。容量隔离需要合适的挂载、配额或其他可执行预算，同时监控应区分临时空间增长与持久状态增长。路径整齐不能替代真正的资源边界。

快速验证

先取得固定镜像，再用宿主 Python 和 Docker 运行脚本。实测为 Docker 29.3.1、Linux arm64，镜像内 Python 3.11.16 提供 SQLite 模块。它创建一个私有命名卷和八 MiB 的 tmpfs 临时挂载，只删除自身容器与卷。小规模临时空间耗尽被限制在实验内部，不修改既有服务存储：

import subprocess,uuid

BASE='python@sha256:528257d48c1da0dcecc2e725d1ae34498d60c965f1241e39cd6a85a8859bdf84'
def docker(*args,check=True):
 result=subprocess.run(['docker',*args],text=True,capture_output=True,timeout=120)
 if check:assert result.returncode==0,result.stderr
 return result
def execute(container,code):return docker('exec',container,'python','-c',code).stdout.strip()

name='xbcatm-state-'+uuid.uuid4().hex[:10];volume=name+'-data';containers=[name+'-one',name+'-replacement']
try:
 docker('volume','create',volume)
 def start(container):
 docker('run','-d','--name',container,'--network','none','--mount','type=volume,src='+volume+',dst=/state','--tmpfs','/scratch:rw,size=8m',BASE,'python','-c','import time;time.sleep(180)')
 start(containers[0])
 execute(containers[0],'from pathlib import Path;import sqlite3;c=sqlite3.connect("/state/data.sqlite");c.execute("create table records(value text)");c.execute("insert into records values (?)",("committed",));c.commit();c.close();Path("/ephemeral").write_text("container-layer");Path("/scratch/crumb").write_text("scratch")')
 docker('stop','--time','1',containers[0]);docker('start',containers[0])
 execute(containers[0],'from pathlib import Path;import sqlite3;assert Path("/ephemeral").exists();assert not Path("/scratch/crumb").exists();c=sqlite3.connect("/state/data.sqlite");assert c.execute("select value from records").fetchall()==[("committed",)];c.close()')
 print('stop/start retains the container writable layer and volume data, while the tmpfs scratch mount loses its file')
 docker('rm','-f',containers[0]);start(containers[1])
 execute(containers[1],'from pathlib import Path;import sqlite3;assert not Path("/ephemeral").exists();c=sqlite3.connect("/state/data.sqlite");assert c.execute("select value from records").fetchall()==[("committed",)];c.close()')
 print('replacement loses the old writable layer but retains the named-volume database')
 execute(containers[1],'''import errno,os,sqlite3
fd=os.open('/scratch/fill',os.O_CREAT|os.O_WRONLY,0o600)
try:
 try:
 while True:os.write(fd,b'x'*1048576)
 except OSError as error:assert error.errno==errno.ENOSPC
finally:os.close(fd)
source=sqlite3.connect('/state/data.sqlite');source.execute('insert into records values (?)',('after-scratch-full',));source.commit()
backup=sqlite3.connect('/state/check-copy.sqlite');source.backup(backup);backup.close();source.close()
restored=sqlite3.connect('/state/check-copy.sqlite');assert restored.execute('select value from records order by rowid').fetchall()==[('committed',),('after-scratch-full',)];restored.close()
''')
 print('bounded scratch reaches ENOSPC while state still commits; a SQLite backup copy reopens with both committed records')
finally:
 docker('rm','-f',*containers,check=False);docker('volume','rm',volume,check=False)

第一个容器在 /state 下创建 SQLite 数据库并提交一条记录，在普通可写层写入 /ephemeral，再把临时文件放进 /scratch。三个路径都通过普通文件接口访问，背后却是不同存储位置。持久应用记录通过 SQLite commit 提交，不依赖尚未关闭的输出缓冲，从而让后续生命周期对照具有明确数据边界。

停止再启动同一个容器后，数据库记录与 /ephemeral 仍存在，临时文件却不见了。启动命令不会重建这些文件，因此观察的是存储寿命，不是初始化逻辑把丢失隐藏起来。这个结果把保留容器时的进程重启，与真正销毁可写层区分开。排查重启后数据行为时，应先确认实际执行了哪一种操作。

随后删除原容器，创建挂载同一命名卷的替换容器。数据库仍含 committed，但 /ephemeral 已不存在。新实例获得新的可写层，同时重新连接保留卷。这证明卷不依赖某个容器的生命周期，却不证明能够抵御 Docker 宿主丢失或卷本身被删除。持久性保证必须附带存储所在位置和删除规则。

接着，替换容器持续写入受限临时挂载，直到返回 ENOSPC。此时仍可向卷中的数据库插入并提交 after-scratch-full。成功提交证明本次配置的容量边界确实生效，不表示持久存储没有上限，也不保证免受其他共享资源耗尽影响，例如宿主总内存。一个隔离维度有效，不能推导所有资源都独立。

最后，通过 SQLite 备份接口创建数据库副本，关闭、重新打开，并按顺序核对两条已提交记录。这里使用数据库自己的复制接口，没有假定随手复制一个正在使用的数据库文件名，就能一致取得所有必要文件。副本仍在相同实验卷上，因此只验证复制可读性与内容，不是独立灾难恢复备份的证据。

让策略跟随数据契约

权威应用数据使用稳定状态目录，可重建工作使用独立管理的临时位置。文件系统层次标准把应用状态与 /var/lib 对应；容器可以选择不同路径，同时保留这种语义区别。通过应用配置明确目录，并说明哪个组件负责创建、权限、清理和迁移。只在部署文档里写路径，而应用实际写向别处，也无法形成有效边界。

有意设置临时预算，并在耗尽时处理错误，不要删除无关状态。缓存只有在权威来源和重建过程确实可用时才可丢弃。一些看似临时的文件，可能是进行中事务或恢复所必需，所以清理需要应用契约，不能仅凭不加区分的年龄规则。删除之前应知道它为何存在，而不是只知道它看起来旧。

独立备份应具有符合数据要求的保留策略，并在新环境中测试恢复。卷跨容器替换保留，是持久性证据，不是备份证据；同卷副本无法抵御该卷整体丢失。监控真实底层存储，核对恢复内容，并把破坏性的卷删除设为明确生命周期决策，才能让目录分离真正服务于数据安全和可维护性。

来源

Docker volumes，独立于容器可写层的数据生命周期，已核验 2026-09-12。
Docker tmpfs mounts，临时内存挂载及大小限制，已核验 2026-09-12。
Filesystem Hierarchy Standard: /var/lib，需要保留的应用可变状态信息，已核验 2026-09-12。
SQLite online backup API，通过数据库接口执行一致复制，已核验 2026-09-12。

fsync 在更新协议中完成存储同步请求

Fri, 27 Nov 2026 00:00:00 +0000

普通 write(2) 成功，可以让实际接受的字节通过内核文件状态被访问，但本身不能建立崩溃持久性。fsync 请求同步文件数据及相关元数据，并等待存储栈报告完成。它是更新协议中的一个操作，仍需要正确顺序、错误检查、目录项处理和底层真实保证。不能只在代码里出现一次 fsync，就推断整个更新已经具有完整事务与恢复语义。

坏掉的样子

用户态缓冲还形成更早一层边界。语言缓冲区尚未把字节提交给内核时，对描述符调用 fsync 无法同步这些字节。应先 flush 缓冲，并检查两个阶段的错误。普通 write 也可能只完成部分写入，延迟存储错误则可能在同步时才出现，而不是在最初写入时报告，因此每层返回结果都需要按契约处理。

同步新建文件，不一定同步命名它的目录项。在 Linux 上，持久创建或替换协议还需要适当的目录同步。原子 rename 提供运行期间的命名空间可见性保证，却不会独立证明目录变化能够经历崩溃保留。当前打开新路径能读到数据，与重启后仍能通过该名字找到预期对象，是不同问题。

fdatasync 不意味着完全不处理元数据。它同步数据，以及后续正确读取数据所需的元数据，包括变化后的文件长度；对于读取不必需的其他元数据更新，则可以省略。把它理解为与 fsync 在所有方面相同，或者完全无视元数据，都会掩盖选择两者的真正依据，应根据应用需要保持的状态理解同步范围。

快速验证

把脚本保存为 syncfile.py，在装有 Python 和 strace 的一次性 Linux 系统中运行 python3 syncfile.py。临时目录必须支持普通文件和目录同步。实测使用 Linux 6.12.76、Python 3.11.2、strace 6.1 和 ext4 卷。样本检查真实调用与运行结果，不会切断存储电源：

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess,sys

program=r'''
from pathlib import Path
import errno,os,sys
root=Path(sys.argv[1]);current=root/'current';candidate=root/'candidate'
current.write_bytes(b'old');old=current.open('rb')
try:
 with candidate.open('wb') as handle:
 handle.write(b'new');handle.flush();os.fsync(handle.fileno())
 os.replace(candidate,current)
 directory=os.open(root,os.O_RDONLY|os.O_DIRECTORY)
 try:os.fsync(directory)
 finally:os.close(directory)
 assert current.read_bytes()==b'new' and old.read()==b'old'
 with current.open('ab') as handle:
 handle.write(b'-extended');handle.flush();os.fdatasync(handle.fileno())
 assert current.read_bytes()==b'new-extended' and current.stat().st_size==12
 read_end,write_end=os.pipe()
 try:
 try:os.fsync(write_end)
 except OSError as error:assert error.errno==errno.EINVAL
 else:raise AssertionError('fsync on a pipe unexpectedly succeeded')
 finally:os.close(read_end);os.close(write_end)
finally:old.close()
print('replacement content, old open reference, appended length, and unsupported-pipe error verified')
'''
with TemporaryDirectory(prefix='xbcatm-fsync-') as directory:
 root=Path(directory);trace=root/'trace'
 result=subprocess.run(['strace','-yy','-s','200','-e','trace=%file,write,fsync,fdatasync','-o',str(trace),'--',sys.executable,'-c',program,str(root)],capture_output=True,text=True,timeout=10)
 assert result.returncode==0,result.stderr
 lines=trace.read_text().splitlines()
 file_sync=next(i for i,line in enumerate(lines) if 'fsync(' in line and str(root/'candidate') in line and '= 0' in line)
 rename=next(i for i,line in enumerate(lines) if line.startswith('rename') and str(root/'current') in line and '= 0' in line)
 directory_sync=next(i for i,line in enumerate(lines) if 'fsync(' in line and '<'+str(root)+'>' in line and '= 0' in line)
 assert file_sync<rename<directory_sync
 assert any('fdatasync(' in line and str(root/'current') in line and '= 0' in line for line in lines)
 print(result.stdout,end='')
 for line in lines:
 if line.startswith(('fsync(','fdatasync(','rename')):print(line)
 print('syscall order verified: flush data, fsync candidate, replace name, fsync parent directory')

子进程创建内容为 old 的当前文件，并保留一份打开读取引用。然后把 new 写入独立候选文件，flush Python 缓冲，再对候选描述符调用 fsync。候选文件位于同一个目录，也使此实验的后续 rename 保持在同一文件系统内，不依赖跨挂载复制等不同操作来模拟替换。

接着替换当前路径，并同步包含它的目录描述符。追踪断言顺序为：候选文件 fsync 成功，rename 成功，父目录 fsync 成功。这些是实际观察到、且检查了返回值的系统调用，不是仅凭注释声明已经遵守同步顺序。程序意图和真实执行之间的对应关系，可以从保留的追踪中核对。

读取当前路径得到 new，先前打开的引用却仍读到 old。这区分原子名字替换与修改全部既有引用：旧引用继续指向原来文件对象，不会因为同名路径换成新文件就自动转移。需要读取新版本的消费者，仍应根据应用发布协议选择对象，不能假定手里已有的句柄会始终代表路径最新状态。

之后子进程追加 extended 后缀，flush 缓冲，再执行 fdatasync。最终内容为 new-extended，长度十二，实际覆盖了文件长度改变后的成功数据同步。这与后续读取所需元数据不能被简单忽略的契约一致，而不是只在内容长度不变的最简单情况里验证调用能够返回。

最后对管道调用 fsync，得到 EINVAL。脚本检查真实失败，没有把任意描述符都当作可同步的普通文件；清理时关闭全部句柄。追踪证明本地内核接受了相应文件与目录请求，却不能独立证明某台物理设备在断电时正确兑现刷新。接口行为与底层故障保证，需要按证据范围分别描述。

定义可以确认提交的边界

应明确哪次更新必须保留，以及读取者允许观察什么。单文件替换中，发布前同步候选，发布后同步受影响目录；跨目录移动还需要考虑两边目录更新。跨文件系统移动采用不同机制，不能假定方便的 rename 协议可以原样适用。更新范围决定哪些对象和命名关系需要被纳入提交边界。

同步失败时，不应报告持久更新已提交。之前写入或 rename 可能已经生效，因此失败不是自动回滚。应保留足够的事务或版本信息，判断实际状态，并按应用契约恢复。fsync 本身不会把多个文件的一系列变化变成单个原子事务，也不会替代应用对于中间状态的处理设计。

应用契约允许时，可以让多项操作共享提交边界，以降低同步成本，但确认应在所需边界成功后发出。还需要在真实存储栈验证崩溃恢复，包括文件系统和设备缓存行为。虚拟化实验中成功的系统调用追踪，可以证明接口执行，却不能替所有下层组件证明各自的故障保证。

来源

fsync(2)，文件目录同步、fdatasync 元数据与错误，已核验 2026-09-12。
rename(2)，原子路径替换与既有打开引用，已核验 2026-09-12。
write(2)，缓冲写入完成、部分写入与延迟错误，已核验 2026-09-12。

写回把缓冲可见性与存储完成分开

Thu, 26 Nov 2026 00:00:00 +0000

缓冲文件 I/O 可以在不同时间经过语言缓冲区、内核页缓存和存储栈。被修改的缓存页需要写回，使数据进入后端文件系统与设备。分开这些阶段可以合并工作、提高吞吐，但也意味着另一读取者看到新字节，本身不能证明已经完成可经历崩溃的存储边界。理解性能和持久性时，需要先确定观察的是哪一层完成。

坏掉的样子

缓冲写入不保证瞬间返回。分配、内存压力、脏页限制或文件系统活动，都可能让写者等待。如果生产速度持续超过存储处理能力，脏数据不能无限增长，压力最终会反映到工作负载。把每次 write 都描述为单纯内存复制、所有 I/O 都在之后发生，会错误解释持续负载下的延迟尖峰。

语言层 flush 与文件系统同步含义不同。flush 把应用缓冲数据提交到下一层，fsync 则请求文件同步边界。普通关闭文件，或者从另一个描述符读到相同字节，不能替代这一显式契约。因此只测成功写入的基准，可能测到的是缓存接受速度，而不是稳定、持久的存储吞吐，需要与实际工作要求对应。

写回设置也不是逐文件持久性截止时间。后台阈值促使刷新线程工作，更高的脏页阈值影响生成写入的进程，周期参数则控制唤醒或较老脏数据何时符合处理条件。设备进展、文件系统行为和竞争负载仍会影响结果。不能仅设一个时间间隔，就证明每次已确认更新在这么多秒后必定安全。

快速验证

把脚本保存为 writeback.py，在装有 Python 和 strace 的 Linux 环境中运行 python3 writeback.py，并让临时目录位于 ext4。实测使用 Linux 6.12.76、Python 3.11.2 和 strace 6.1。样本写入约四 MiB、读取记账信息，不改变全局脏内存参数或缓存控制：

from pathlib import Path
from tempfile import TemporaryDirectory
import subprocess,sys

program=r'''
from pathlib import Path
import json,os,subprocess,sys
root=Path(sys.argv[1]);path=root/'data'
def io():return {key:int(value) for key,value in (line.split(':',1) for line in Path('/proc/self/io').read_text().splitlines())}
def dirty():return int(next(line.split()[1] for line in Path('/proc/meminfo').read_text().splitlines() if line.startswith('Dirty:')))
with path.open('wb',buffering=65536) as handle:
 handle.write(b'buffered')
 assert path.stat().st_size==0 and path.read_bytes()==b''
 before=io();handle.flush();after=io()
 assert after['wchar']-before['wchar']>=8
 reader='from pathlib import Path;import sys;assert Path(sys.argv[1]).read_bytes()==b"buffered"'
 subprocess.run([sys.executable,'-c',reader,str(path)],check=True)
 print('visible before explicit fsync',flush=True)
 before=io();chunk=b'x'*(4*1024*1024);handle.write(chunk);handle.flush();after=io()
 assert after['wchar']-before['wchar']>=len(chunk)
 assert after['write_bytes']-before['write_bytes']>=len(chunk)
 dirty_before=dirty();os.fsync(handle.fileno());dirty_after=dirty()
 assert path.stat().st_size==len(chunk)+8
 print(json.dumps({'wchar_delta':after['wchar']-before['wchar'],'write_bytes_delta':after['write_bytes']-before['write_bytes'],'system_dirty_kib_before':dirty_before,'system_dirty_kib_after':dirty_after}))
'''
with TemporaryDirectory(prefix='xbcatm-writeback-') as directory:
 root=Path(directory);trace=root/'trace'
 result=subprocess.run(['strace','-f','-yy','-s','200','-e','trace=write,fsync,fdatasync','-o',str(trace),'--',sys.executable,'-c',program,str(root)],capture_output=True,text=True,timeout=10)
 assert result.returncode==0,result.stderr
 lines=trace.read_text().splitlines()
 visible=next(i for i,line in enumerate(lines) if 'visible before explicit fsync' in line)
 syncs=[i for i,line in enumerate(lines) if 'fsync(' in line and str(root/'data') in line]
 assert len(syncs)==1 and visible<syncs[0] and '= 0' in lines[syncs[0]]
 print(result.stdout,end='');print(lines[syncs[0]])
 print('another process read flushed bytes before the only explicit file synchronization; global Dirty is observational, not an isolated-device counter')

子进程用六万五千五百三十六字节的 Python 缓冲打开文件，并写入八字节。flush 前，路径报告长度零，独立打开也读不到内容，因为数据仍在应用缓冲里。这个对照直接建立最早的边界，没有假定每次语言级 write 都已经发出内核写入。应用接口返回与系统调用发生，需要分别确认。

flush 后，进程的成功写入字节计数增加，另一个子进程读到预期内容。写者在唯一一次显式 fsync 前打印标记，strace 记录确认可见性标记确实先于同步。结果证明，应用请求这个存储边界之前，其他进程已经能观察新数据，因此“别人读到了”不能单独证明更新已经持久。

写者随后再提交四 MiB，检查 wchar 和 write_bytes 都增加。两项计数回答不同记账问题，分别涉及成功 write 类调用的字节，以及归属于该进程的存储写入活动。它们不能直接替换成业务负载数量、设备完成时间戳，或者证明更新可抵御断电的证书。计数增加说明所记录活动发生，不自动包含更多保证。

样本在成功 fsync 前后记录系统 Dirty，并检查最终文件长度。记录中的两个值为四千一百四十八和五十六 KiB，但它们是聚合内核视图，不是这一个文件脏页的隔离测量。其他活动和正常写回都能改变这些值，因此测试不会断言所有环境都有固定下降量或完全相同结果。

生成文件全部位于临时目录，追踪检查唯一一次显式文件同步成功。实验建立了缓冲、可见性和接口顺序，却没有执行断电、预测设备最大写延迟，也没有证明一个聚合计数能解释所有存储行为。实际分析应使用对应层级的证据，不能把观察到的相关变化直接扩大为普遍因果关系。

测量工作负载真正需要的边界

应一起追踪写入延迟、同步延迟、脏页与写回状态，以及相关设备或 cgroup 活动。最初突发很快、随后停顿，可能反映缓存先吸收数据，之后受到排空速度限制。测试应持续到覆盖工作负载需要的稳定路径，而不是只报告缓存最初的接受速度，再据此推断设备能够长期维持相同吞吐。

配置的脏页阈值需要谨慎解释。比例参数使用符合条件的可用内存，不等于全部安装内存；字节参数表达另一种限制。提出调整前应读取实际生效设置。减少积累可能改善某种延迟，却增加写活动；扩大积累可以推迟压力出现，却不会提高设备本身处理速度，不能把缓存额度当成存储能力。

应用应定义何时允许确认提交。数据库可以让多笔提交共享合适的日志同步边界，可重建缓存则可能接受丢失。后台写回改善普通缓冲路径，却不会替应用创造这份业务契约。应检查写入与同步错误，并按承诺的持久边界验证恢复，才能把性能取舍与允许丢失的范围明确对应起来。

来源

write(2)，缓冲写入可见性、完成与延迟存储错误，已核验 2026-09-12。
Linux virtual-memory sysctl documentation，脏页阈值、后台写回与周期计时，已核验 2026-09-12。
proc_pid_io(5)，进程 I/O 记账与不同字节计数含义，已核验 2026-09-12。
proc_meminfo(5)，Dirty 与 Writeback 内存观察，已核验 2026-09-12。
fsync(2)，显式文件同步与失败报告，已核验 2026-09-12。

文件系统 · XB 现场笔记

扩展属性属于 inode，也受命名空间约束

坏掉的样子

快速验证

在整个流程中保留含义

来源

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

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

空间到底去了哪里

还原点不是副本

坏掉的样子

快速验证

来源

inotify 报告变化，但不是完整历史记录

坏掉的样子

快速验证

协调路径和对象寿命

来源

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

坏掉的样子

快速验证

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

来源

硬链接共享 inode，替换名字后关系会改变

坏掉的样子

快速验证

检查身份和实际更新方式

来源

符号链接保存路径，不永久绑定目标身份

坏掉的样子

快速验证

分别确定对象与遍历策略

来源

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

文件与表

选项真正决定了什么

挂载，以及 id 映射陷阱

坏掉的样子

快速验证

来源

只读根在其范围内限制文件系统修改

坏掉的样子

快速验证

分开打包文件、临时空间与持久状态

延伸阅读

来源

文件锁保护共同协议中的特定对象

坏掉的样子

快速验证

明确所有参与者遵守的协议

来源

让持久状态和临时空间拥有不同生命周期

坏掉的样子

快速验证

让策略跟随数据契约

延伸阅读

来源

fsync 在更新协议中完成存储同步请求

坏掉的样子

快速验证

定义可以确认提交的边界

延伸阅读

来源

写回把缓冲可见性与存储完成分开

坏掉的样子

快速验证

测量工作负载真正需要的边界

来源