The full picture
- Name resolution:
/var/log/app.log= walk root dir file → find 'var' inode → read that dir → 'log' → dir → 'app.log' inode — cached aggressively in the dentry cache (why firstls -Ris slow, second is instant). - Unlink-while-open, the ops classic: delete a 50GB log the process still has open →
dfshows no space freed (inode alive via FD) butducan't see it. Find withlsof +L1; fix by truncating or bouncing the process. This feature is also how tmpfile security works. - Journal modes matter operationally: metadata-only journaling (ext4 default
data=ordered) guarantees FS structure survives crashes — not your latest file contents; full-data journaling is safer and slower. Copy-on-write file systems (ZFS, btrfs) get atomicity differently — never overwrite in place, flip a root pointer. - The WAL isomorphism: journal = redo log; checkpoint = applying it; replay-on-mount = crash recovery. If you understand Postgres WAL or Kafka's log, you already understand ext4's journal — say so, it collapses the question.