Файловая система и inode'ы

Что отвечать

Inode - структура метаданных файла в ядре: владелец, права, размер, timestamps, указатели на блоки данных. Имя файла - это запись в каталоге, которая связывает строку имени с номером inode. Файл - это inode плюс его данные; имя - только ярлык. Один inode может иметь несколько имён (hard link); файл с открытым fd живёт до закрытия даже после `rm`.

Что хотят услышать

Кандидат должен: - различить три сущности: inode (хранит метаданные), data blocks (хранят содержимое), directory entry (связывает имя и inode) - объяснить почему `rm` не освобождает место сразу, если есть открытый fd: ядро декрементирует link-count, но при `i_count > 0` физическое освобождение откладывается до закрытия - назвать `ls -i` и `stat` как инструменты увидеть inode-номер - объяснить почему inode-таблица ограничена при `mkfs` (поэтому `df -i` важен на FS с миллионами мелких файлов)

Подводные камни

• ✗ Сказать «файл = имя» - нет, имя это только ссылка на inode
• ✗ Не знать про `df -i` - типичная причина «места есть, а файл не создаётся»
• ✗ Думать что `rm` освобождает место мгновенно - нет, если кто-то держит fd

Follow-up

• ? Что делает `lsof | grep deleted`? Зачем это нужно?
• ? Можно ли создать файл, если все inode исчерпаны, но место есть?
• ? Чем отличается ext4 inode-структура от XFS?

Что отвечать

Hard link - второе имя для того же inode; неотличимо от оригинала, у обоих одинаковый inode-номер, и удаление одного из имён не трогает данные пока жив хотя бы один link. Symbolic link - отдельный файл со своим inode, содержит путь к цели. Symlink может указывать на несуществующий путь и на файлы на другой FS; hard link - только на тот же FS и не на каталог.

Что хотят услышать

Senior должен: - назвать ограничения hard link: только в пределах одной FS, не на каталоги (кроме `.` и `..` от ядра) - объяснить почему hard link на каталог запрещён: иначе FS-дерево перестало бы быть деревом и `find /` зациклился бы - сказать что `cp -a` копирует symlink как symlink (не следует), а `cp -L` следует за ним - упомянуть `readlink -f` для получения канонического пути с развёрнутыми symlink'ами

Подводные камни

• ✗ Перепутать поведение `rm` на оригинале - для hard link оригинал не имеет статуса, для symlink удаление цели сделает ссылку битой
• ✗ Сказать что symlink быстрее hard link - оба O(1), разницы нет
• ✗ Не знать что symlink может указывать на другую FS, а hard link - нет

Follow-up

• ? Почему `mv` через границы FS физически копирует файл, а в пределах FS - нет?
• ? Что выведет `stat symlink` vs `stat -L symlink`?
• ? Как работает bind mount и чем он отличается от symlink на каталог?

Что отвечать

`df` смотрит на superblock - сколько занято на уровне FS, включая открытые-но-удалённые файлы и sparse-области. `du` обходит каталоги и суммирует размер видимых файлов. Если процесс держит fd на удалённый гигабайтный лог - `df` показывает что место занято, `du` его не видит. Решение: найти процесс через `lsof | grep deleted` и пнуть его (graceful: SIGHUP для reopen, hard: рестарт).

Что хотят услышать

Кандидат должен назвать три типичные причины расхождения: - открытые удалённые файлы (самое частое; lsof находит) - sparse-файлы (du по умолчанию считает «дырки» как занятое место, реальный disk usage меньше - нужен `du --apparent-size` для видимого размера) - reserved blocks (`tune2fs -m` по умолчанию 5% для root) - `df` показывает их «занятыми», `du` их не видит - mount overlay (контейнер видит только свой слой, host видит всё)

Подводные камни

• ✗ Думать что это всегда баг - обычно это feature, открытый fd
• ✗ Не знать про `lsof | grep deleted` - главный инструмент диагностики
• ✗ Перепутать `du` и `du --apparent-size` на sparse-файлах

Follow-up

• ? Как именно SIGHUP заставляет syslog переоткрыть лог-файл?
• ? Что произойдёт с открытым fd при `truncate -s 0 file.log`?
• ? Почему `df` на overlay-FS в Docker может врать вдвое?

Что отвечать

`write()` копирует данные в page cache ядра и возвращается; данные ещё в RAM. `fsync(fd)` блокирует процесс пока ядро не сольёт грязные страницы этого файла на физический носитель и не дождётся подтверждения от диска. До `fsync` крах ядра или power loss теряет всё, что висело в page cache. БД и любая система с durability-гарантиями вызывает fsync на каждый commit.

Что хотят услышать

Senior должен: - различить `fsync` (данные + метаданные), `fdatasync` (только данные, быстрее на ext4 для существующих файлов), `sync` (всё в системе) - назвать что `O_DSYNC`/`O_SYNC` флаги при open делают каждый write синхронным - медленно, но без явных fsync - объяснить роль write barrier и почему RAID-контроллеры с battery-backed cache могут безопасно lie ядру про fsync (питание не пропадёт даже при power loss) - упомянуть что NVMe SSD с power-loss-protection дают истинный fsync за единицы микросекунд, обычный consumer SSD - миллисекунды

Подводные камни

• ✗ Думать что `write()` сразу пишет на диск - нет, только в page cache
• ✗ Забыть про метаданные - `fsync` синхронизирует и их, `fdatasync` нет
• ✗ Не знать про write barrier и почему на virtual disk fsync может быть NO-OP (если виртуализация игнорирует)

Follow-up

• ? Зачем PostgreSQL делает fsync на WAL, а не на data files?
• ? Что такое write barrier и зачем он нужен для FS journal?
• ? Чем `fsync` отличается от `msync` для memory-mapped файлов?

Что отвечать

Это security hardening для каталогов, куда писать может непривилегированный юзер. `noexec` - запрет запускать бинари с этой FS (даже если у файла +x). `nosuid` - игнорировать SUID-бит (бинарь не получит привилегии владельца). `nodev` - запрет интерпретировать device-файлы. Типичный набор для `/tmp`, `/dev/shm`, `/var/tmp`, `/home` на shared-серверах.

Что хотят услышать

Кандидат должен: - объяснить угрозу: атакующий пишет SUID-бинарь в `/tmp` → запускает → получает root. `nosuid` это блокирует - назвать что `noexec` обходится через `bash script.sh` (запускается bash, а не script) или через `/lib/ld-linux.so script` - это не абсолютная защита - упомянуть CIS-benchmark, где эти опции - обязательный пункт для prod-серверов - сказать что эти опции применяются только к самой FS, не к bind-mount'ам автоматически - bind-mount наследует исходные опции

Подводные камни

• ✗ Думать что `noexec` полностью запрещает выполнение - `bash file` обходит
• ✗ Применять `nodev` на `/dev` - там лежат сами device-файлы, сломается всё
• ✗ Не знать что `mount -o remount,noexec /tmp` применит на лету

Follow-up

• ? Как `mount --bind` копирует/не копирует mount-options источника?
• ? Почему `/proc` обязан быть `nosuid,nodev,noexec` по умолчанию?
• ? Что произойдёт если переключить `/tmp` на `nosuid` пока работают процессы, открывшие там временный файл?

Что отвечать

Каталоги стандартизированы FHS (Filesystem Hierarchy Standard). `/etc` - конфиги системы и сервисов, `/var/log` - логи, `/var/cache` - пересоздаваемые кэши (можно удалить), `/var/lib` - состояние сервисов (нельзя удалять), `/usr/local` и `/opt` - софт не из пакетов, `/tmp` - эфемерное между ребутами (часто tmpfs), `/run` - runtime-state (всегда tmpfs). Эта схема исторически отделяет read-only от mutable, чтобы можно было монтировать `/usr` как ro.

Что хотят услышать

Senior должен: - различить `/var/log` (логи приложений) и `/run` (PID-файлы, sockets, ничего не переживает ребут) - сказать почему `/var/cache` можно безболезненно очистить, а `/var/lib` - нет (там БД сервисов, sessions, очереди) - назвать XDG Base Directory Spec для user-level конфигов (`~/.config`, `~/.local/share`, `~/.cache`) - объяснить почему `/usr/local` для собранного из исходников, а `/opt` - для self-contained third-party (Chrome, Atlassian)

Подводные камни

• ✗ Класть state в `/var/cache` - после `apt clean` или CI-cleanup сервис потеряет данные
• ✗ Не знать про `/run` - на современных дистро `/var/run` это симлинк на `/run`, в скриптах часто пишут устаревший путь
• ✗ Путать `/usr/local` и `/opt`

Follow-up

• ? Почему `/usr/bin` слился с `/bin` в современных Debian/RHEL? (UsrMerge)
• ? Что лежит в `/sys` и чем оно отличается от `/proc`?
• ? Зачем существует `/var/spool` и какие сервисы им пользуются?