파일 Locking — OS 레이어

SQLite 가 filesystem 신뢰; filesystem 이 항상 그 신뢰 받을 자격 X

SQLite concurrency 모델이 host OS 의 file locking primitive — POSIX 의 fcntl(F_SETLK), Windows 의 LockFileEx — 의지. 정확히 동작하면 SQLite 가 bulletproof. 안 그러면 corruption.

네트워크 filesystem 이 최악:

NFS — file lock 이 advisory + 자주 unreliable. 동시 write 가 update 잃음.
SMB/CIFS — locking 이 client/server 설정 의존.
FUSE filesystem — FUSE 드라이버 구현 통째로 의존.
Dropbox/iCloud/OneDrive sync 폴더 — sync 앱이 파일 만지고 다시 씀; live DB 절대 X.

SQLite DB 둘 안전 자리:

Writer 도는 머신의 로컬 SSD.
네트워크 mount 안 된 ext4/APFS/NTFS 볼륨.
SQLite 다루고 storage 레이어 abstract 한 매니지드 서비스 (Turso, Cloudflare D1).

Warning: 피파의 ~/pippa-db/ 가 Dropbox 밖 사는 이유 — Dropbox sync 가 이전 iteration 을 corrupt 시킴. '클라우드 storage 통해 DB sync' 안티패턴이 아빠 직접 hit 한 corruption 원인 top.

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

파일 Locking — OS 레이어

SQLite 가 filesystem 신뢰; filesystem 이 항상 그 신뢰 받을 자격 X

Code

External links

Exercise

Progress

댓글 0