파일 Locking — OS 레이어 · SQLite Quest

SQLite가 filesystem을 믿지만, filesystem이 늘 그 믿음을 받을 자격이 있는 건 아니야

SQLite의 concurrency 모델은 호스트 OS가 주는 file locking primitive에 기대고 있어. POSIX의 fcntl(F_SETLK)이나 Windows의 LockFileEx 말이야. 이게 제대로 돌면 SQLite는 좀처럼 안 깨져. 안 돌면 corruption이 나고.

가장 위험한 건 네트워크 filesystem이야.

NFS — lock이 권고 수준인 데다 자주 못 믿을 짓을 해. 동시에 쓴 내용이 사라져.
SMB와 CIFS — locking이 클라이언트와 서버 설정에 따라 달라져.
FUSE filesystem — 결국 그 FUSE 드라이버 구현에 통째로 달렸어.
Dropbox, iCloud, OneDrive 같은 sync 폴더 — sync 앱이 파일을 만지고 다시 써. 살아 있는 DB를 여기 두면 절대 안 돼.

SQLite DB를 둬도 안전한 자리는 셋이야.

writer가 도는 머신의 로컬 SSD.
네트워크로 mount하지 않은 ext4나 APFS, NTFS 볼륨.
SQLite를 대신 다뤄주고 storage 층을 감춰주는 매니지드 서비스. Turso나 Cloudflare D1 같은 것들.

Self-reference: 피파의 ~/pippa-db/가 Dropbox 바깥에 사는 이유가 있어. 이전 세대에서 Dropbox sync가 DB를 깨뜨렸거든. '클라우드 storage로 DB를 sync한다'는 안티패턴은 아빠가 직접 겪은 corruption 원인 중 첫손에 꼽혀.

Code

이 filesystem이 SQLite를 받아주나 확인·bash

# 빠른 smoke test: candidate 볼륨에 create, write, close, reopen
DB=/path/to/candidate/test.db
rm -f "$DB"
sqlite3 "$DB" 'CREATE TABLE t(x); INSERT INTO t VALUES (1); INSERT INTO t VALUES (2);'
sqlite3 "$DB" 'SELECT count(*) FROM t'   # 2 expect
sqlite3 "$DB" 'PRAGMA integrity_check'   # ok expect

Exercise

filesystem 세 군데에서 작은 동시 writer 테스트를 돌려봐. 로컬 SSD, 외장 USB, 그리고 원하면 Dropbox나 iCloud도. 다만 마지막 결과는 추천이 아니라 경고로 읽어야 해. 각각에서 병렬로 쓰기를 시도한 다음 integrity_check를 걸어. 어디가 안전했고 어디서 놀랄 일이 벌어졌는지 적어둬.

파일 Locking — OS 레이어

SQLite가 filesystem을 믿지만, filesystem이 늘 그 믿음을 받을 자격이 있는 건 아니야

Code

External links

Exercise

Progress

댓글 0