Component
ckpt
Bug Description
ws-ckpt daemon 在做 checkpoint 之前，会先检查 workspace 的 inotify 写标志。本意是"如果还在写就等一下，等写完再快照"，听起来挺合理。但实际实现是个只置位、不自动清零的锁存：
- 任何一个写事件（
Create / Modify / Remove）进来，flag 就被置 true
- 整个代码里没有任何地方在写完后把 flag 清回 false
- 唯一会清零的地方是
check_quiescent() 自己，而且是在它已经决定"我要走 quiesce 流程"之后才清
结果就是：只要这个 workspace 在历史上发生过任何一次写操作（哪怕 10 分钟前写完，文件早就 close 了），下一次 checkpoint 必定走完整的 quiesce 等待——两次 sleep(100ms)，固定 +200ms。
实测对比：
| 场景 |
实测耗时 |
| 纯快照（不走 quiesce 分支） |
~10ms |
| checkpoint（命中 quiesce 锁存） |
~213ms |
也就是说快照本身只花 10ms，但 quiesce 协议白白吃掉了 20 倍的时间。
Steps to Reproduce
mkdir -p /tmp/test && echo x > /tmp/test/f.txt
ws-ckpt init -w /tmp/test
# 场景 1：写入后立即 checkpoint —— 必定 ~213ms
dd if=/dev/urandom of=/tmp/test/f.txt bs=1K count=1 2>/dev/null
time ws-ckpt checkpoint -w /tmp/test -i t1
# 场景 2：不写入直接 checkpoint —— ~10ms
time ws-ckpt checkpoint -w /tmp/test -i t2
注意：场景 2 必须是"从来没写过的 workspace"，或者你能保证从上次 quiesce 之后没有任何写事件。实际生产环境基本不存在这种情况。
Expected Behavior
现在的 flag 语义是"曾经写过"，这没意义。改成"当前还有文件没关闭"才合理：
- 监听
CLOSE_WRITE 事件，在文件关闭时把 flag 清回 false
- 只有 flag 真的是 true（确实还有文件在写）才走 quiesce 等待
- 写完后的 checkpoint 直接 fast path，10ms 搞定
Environment
alinux4
Relevant Log Output
Additional Context
No response
Component
ckpt
Bug Description
ws-ckpt daemon 在做 checkpoint 之前，会先检查 workspace 的 inotify 写标志。本意是"如果还在写就等一下，等写完再快照"，听起来挺合理。但实际实现是个只置位、不自动清零的锁存：
Create/Modify/Remove）进来，flag 就被置truecheck_quiescent()自己，而且是在它已经决定"我要走 quiesce 流程"之后才清结果就是：只要这个 workspace 在历史上发生过任何一次写操作（哪怕 10 分钟前写完，文件早就 close 了），下一次 checkpoint 必定走完整的 quiesce 等待——两次
sleep(100ms)，固定 +200ms。实测对比：
也就是说快照本身只花 10ms，但 quiesce 协议白白吃掉了 20 倍的时间。
Steps to Reproduce
注意：场景 2 必须是"从来没写过的 workspace"，或者你能保证从上次 quiesce 之后没有任何写事件。实际生产环境基本不存在这种情况。
Expected Behavior
现在的 flag 语义是"曾经写过"，这没意义。改成"当前还有文件没关闭"才合理：
CLOSE_WRITE事件，在文件关闭时把 flag 清回 falseEnvironment
alinux4
Relevant Log Output
Additional Context
No response