Record why the remaining store ideas wait

The zero tail wrote as many bytes as the commits under 64 writers, yet
turning it off changed nothing beyond the SD card's own noise and made
8 writers wait longer, so it stays until faster storage is measured.
Overlapping a sync with the next burst would win a few percent at most.
The second sync of a new process's first commit is rare with one owning
server. The larger lever is write amplification: a 16-byte edit rewrites
its whole leaf and catalog path.

1 files changed, 16 insertions, 3 deletions

diff --git a/docs/research/076-one-sync-commit.md b/docs/research/076-one-sync-commit.md
index 8176a82..9f010e7 100644
--- a/docs/research/076-one-sync-commit.md
+++ b/docs/research/076-one-sync-commit.md
@@ -139,6 +139,19 @@ SQLite WAL은 프레임마다 누적 체크섬을 두어 커밋당 동기화 한
 
 ## 다음 결정
 
-1. 꼬리를 늘리는 비용을 커밋 경로에서 빼기(백그라운드 준비나 세그먼트 재사용). 지금은 한 커밋이 치른다.
-2. 여러 프로세스가 같은 저장소를 쓸 때의 확인 동기화를 줄이는 방법(동기화 완료를 공유 메모리로 알리기).
-3. 동기화를 다음 묶음의 실행과 겹치기. 커밋 결과를 기다리는 동안 다음 묶음의 이벤트를 준비한다.
+뒤따른 측정(2026-09-26, 묶음 한도를 256키로 올린 뒤 연결 64개 쓰기)으로 세 후보를 다시 봤다.
+
+1. **꼬리 0 채우기.** 이 부하에서는 커밋 하나가 약 46 KB를 쓰고(문서 26개의 leaf와 카탈로그), 0 채우기도 같은 양을
+   썼다(3초에 데이터 8.3 MB, 0 8.6 MB). 서버 시간의 88%가 `fdatasync`였다(p50 5.5 ms, p90 24.5 ms). 꼬리를 끈
+   판과 번갈아 쟀지만 처리량 차이는 SD 카드의 흔들림(같은 설정이 1,832–3,107/s) 안에 있었다. 연결 8개의 p50은 꼬리가
+   있을 때 짧았다(6.4–7.4 ms 대 11.8–12.8 ms). 그래서 꼬리는 유지한다. 백그라운드 준비나 공간 재사용은 저장 장치를
+   바꿔(SSD·NVMe) 저널 커밋과 0 쓰기의 비용 비율을 다시 잰 뒤에 정한다.
+2. **동기화와 다음 묶음 겹치기.** 묶음 하나의 CPU 일은 약 50–100 µs이고 동기화는 2.5–14 ms다. 겹쳐도 얻는 것은
+   몇 퍼센트다. 또 다음 커밋의 헤드는 앞 커밋이 내구성을 얻기 전에 쓸 수 없다(두 슬롯 복구의 전제). 보류한다.
+3. **다른 프로세스의 확인 동기화.** 짧은 명령(`aup run --store`)의 첫 커밋이 동기화를 두 번 한다. 쓰기 잠금 파일에
+   "마지막으로 내구성을 얻은 헤드"를 적어 두는 방법이 있다. 다만 재부팅 뒤에는 믿을 수 없으므로 부팅 식별자를
+   함께 적어야 한다. 서버 한 개가 저장소를 소유하는 지금의 배치에서는 드물어 보류한다.
+
+더 큰 방향은 쓰기 증폭이다. 16 B를 고쳐도 그 leaf 전체(최대 4 KiB)와 카탈로그 경로를 다시 쓴다. 작은 편집을
+로그에 델타로 적고 leaf 재작성을 나중에 모아 하는 방식(WAL과 체크포인트, 또는 델타 사슬)이면 커밋 바이트가
+수십 분의 일로 준다. 대신 다른 프로세스의 읽기가 델타를 적용해야 한다. 저장소 설계를 바꾸는 일이라 따로 연구한다.