Файловые системы и синхронизация

Краткое резюме

Файловая система — это баланс целостности, производительности и операций. Синхронизация — это про модель согласованности и разрешение конфликтов, а не только «скопировать файлы». Начинаем с требований (p95 latency, RPO/RTO, тип нагрузки), выбираем ФС и протокол, настраиваем журналирование и блокировки, задаем SLO, автоматизируем снапшоты/версионирование и используем корректные инструменты синхронизации.

Выбор файловой системы под нагрузку

Универсальные Linux ФС

ext4 — стабильная «рабочая лошадка». Опции: `noatime, nodiratime, discard(с осторожностью), data=ordered`. Хорош для VM-дисков, общих каталогов, CI-артефактов.
XFS — сильна на больших файлах/параллелизме (медиаконтент, логи, DWH). Опции: `noatime, inode64`; под большие файлы стоит настроить `reflink=1` (clone).
ZFS — CoW, проверка целостности, снапшоты/реплика `send/recv`, ARC/L2ARC, ZIL/SLOG для sync. Отлична для бэкапов, NAS, базовых пулов с требованием целостности.
Btrfs — CoW, снапшоты/сжатие/RAID в userspace; хорошо под dev/test и edge, осторожнее для OLTP без тюнинга.

Windows/кроссплатформа

NTFS — ACL, ADS, надежен для SMB; `DisableLastAccess` для производительности.
exFAT — съемные носители, без прав и журналирования (не для прод).

Настройки, влияющие на надежность и скорость

Журналирование и барьеры: `data=ordered` (ext4 по умолчанию) — баланс; `data=journal` — безопаснее, но медленнее; убедитесь, что write barriers включены (или контроллер с BBU/PLP).
fsync/sync: критичные потоки (журналы/транзакции) должны явно вызывать `fsync()`; иначе потеря при аварии возможна.
atime: `relatime`/`noatime` снижает write-давление.
xattr/ACL: включайте, если нужны POSIX ACL и метки безопасности.
Размер блоков/recordsize: ZFS `recordsize=16K` для БД; `1M` для больших медиа.

Примеры монтирования:

bash ext4 for CI artifacts
UUID=... /var/lib/ci ext4 noatime,nodev,nosuid,data=ordered 0 2
XFS for Media Directories
UUID=... /srv/media xfs noatime,attr2,inode64 0 0
ZFS for backups and snapshots (creation)
zpool create tank mirror nvme0n1 nvme1n1 zfs set compression=lz4 atime=off tank/backups

Сетевые и распределенные файловые системы

NFS/SMB (NAS-подход)

NFSv3/v4: просто и быстро; v4 дает блокировки и Kerberos (`sec=krb5p`). Не полагайтесь на NFS для высокочастотных «глубоких» fsync — лучше локальный диск + асинхронная выгрузка.
SMB 3.x: multichannel, шифрование, интеграция с AD. Включайте подписывание/шифрование на чувствительных данных.

Экспорт NFS (минимум):


/pool/projects 10. 0. 0. 0/16(rw,no_root_squash,sec=krb5p,async)

SMB (фрагмент):


[reports]
path = /pool/reports read only = no vfs objects = acl_xattr, recycle smb encrypt = required

Распределенные FS

CephFS — POSIX поверх Ceph; хорош для горизонтального масштаба, снапшоты, квоуты, метаданные распределены.
GlusterFS — прост в стартe, реплика/шардинг, но аккуратно с маленькими файлами и p99.
Lustre/IBM Spectrum Scale — HPC/большие файлы, требовательны к сети/операциям.
9P (Virtio-fs) — для VM-шеринга, не для прод-нагрузок с жесткими SLO.

Рекомендация: для OLTP/кошельков — не сетевой FS; используйте блочные тома. Для статического контента/общих артефактов — NFS/SMB/объектка + CDN.

Блокировки, кэширование и согласованность

Advisory vs mandatory locks: Linux обычно advisory; SMB поддерживает oplocks/leases, NFSv4 — stateful locks.
Кэширование клиента: агрессивные кеши ускоряют чтение, но при мульти-клиентах увеличивают риск конфликтов.

Согласованность:

Strong (локальные ФС, ZFS).
Close-to-open (NFS): изменения видны при `close()/open()`.
Eventual (некоторые распределенные/объектные сценарии).
Часы: NTP/PTP; дрейф времени ломает конфликт-резолв и TTL.

Синхронизация: модели и инструменты

Модели

One-way (push/pull): публикация артефактов, выгрузка отчетов, offsite-бэкап.
Two-way (bi-dir): совместная работа; требуются конфликт-резолвер и версионирование.
Hub-and-spoke: звезда через центральный узел/кластер (MinIO/S3 + агенты).
Near-real-time vs batch: inotify/логи изменений vs периодические окна.

Инструменты

rsync — де-факто стандарт one-way; `--delete`, `--partial`, `--inplace` (осторожно).
rclone — S3/облака, проверка хэшей, серверный-side copy.
Unison — true bi-directional, разрешение конфликтов.
Syncthing — p2p, версионирование, удобно для рабочих папок.
lsyncd — триггер rsync по inotify; near-real-time.
ZFS send/recv — идеальный «синк» снапшотов/инкрементов (байтово эффективно).

rsync (one-way, публикация статического каталога):

bash rsync -az --delete --numeric-ids --partial --inplace \
/srv/builds/ user@edge:/var/www/builds/

Unison (bi-dir, профиль):


root =/srv/shared root = ssh ://user @ peer//srv/shared prefer =/srv/shared # in case of conflict - local side repeat = watch # inotify ignore = Name. tmp

lsyncd (near-real-time поверх rsync):

lua settings { logfile="/var/log/lsyncd. log", statusFile="/var/run/lsyncd. status" }
sync {
default. rsync,
source="/srv/outbox",
target="user@remote:/srv/inbox",
rsync={ archive=true, compress=true, delete=true }
}

ZFS реплика (инкремент):

bash zfs snapshot tank/data@now zfs send -i tank/data@prev tank/data@now      ssh backup zfs recv -F backup/data

Версионирование, снапшоты и «корзины»

Снапшоты CoW (ZFS/Btrfs/CephFS): быстрые точки отката, мин. накладные.
Версионирование на уровне приложения (Nextcloud/Syncthing/объектка): удобно для пользователей.
Корзины/рециклы на SMB/NFS: спасают от случайного удаления, но не заменяют бэкап.

Безопасность и доступ

ACL и xattr: POSIX ACL, SID/ACE для SMB, маппинг uid/gid.
Чтение/запись через шлюзы: SFTP/HTTPS/WebDAV — когда нельзя открывать SMB/NFS наружу.
Шифрование: LUKS/ZFS native; в полете — Kerberos (NFSv4), SMB encryption, TLS для шлюзов.
PII/комплаенс: сегментация шар, строгие маски прав, аудиты доступа, WORM там, где нужно неизменяемо.

Наблюдаемость, SLO и алерты

Метрики ФС: p95/p99 latency (read/write/open), IOPS, qdepth, cache hit, inode usage, fill-level, errors (EIO/ENOSPC).
Сетевые метрики (NFS/SMB): retransmits/drops, RPC RTT, oplock breaks, queue length.

SLO (примеры):

NFS-шара CI: p95 `open`/`read` ≤ 3–5 мс, доступность ≥ 99.95%.
SMB отчеты: p95 листинг каталога ≤ 100 мс при ≤ 10k файлов/дир.
ZFS пул бэкапов: p99 запись ≤ 10 мс, успех снапшотов 100%, RPO ≤ 15 мин (инкременты).

Алерты:

Заполнение пула > 80/90/95%, рост `EIO`, лаг снапшотов, падение hit-ratio, частые oplock-break.

Паттерны для продукта (iGaming/финтех)

Статика (иконки/превью/каталоги провайдеров): публикация через rsync → CDN; хранить первоисточник в объектке с версионированием.
Логи и «сырые» события: писать локально (XFS/ext4) → батчево выгружать (rclone → S3/MinIO).
Отчетность и PII: SMB с шифрованием и строгими ACL; периодический offsite-экспорт (ZFS send/recv) с WORM на приемной стороне.
Dev-среды и фиксация артефактов: NFS/SMB для шаринга; для тяжелых баз — блок-тома + снапшоты.
Коллаборация контента: Syncthing/Nextcloud с версионированием и квотами.

Чек-лист внедрения

Определены классы данных (горячее/холодное/PII), RPO/RTO и SLO.
Выбрана ФС: ext4/XFS/ZFS с корректными опциями (noatime, barriers, recordsize).
Если NAS: NFSv4/SMB с шифрованием/подписями, ACL, Kerberos/AD.
Снапшоты/версионирование/корзины — настроены и проверены восстановлением.
Инструмент синка под задачу: rsync (one-way), Unison/Syncthing (bi-dir), rclone (облако), ZFS send/recv (бэкап/DR).
Мониторинг ФС/сети/операций, burn-rate SLO, алерты ENOSPC/EIO/oplock.
Документация: Runbook конфликтов, регламент fsync, политика именований/длин путей/кодировок.
Тесты: нагрузочные профили (мелкие/крупные файлы), кат-сценарии (разрыв связи, конфликт редактирования).

Типичные ошибки

Общая сетевая шара для критичных транзакций (OLTP) вместо локального блочного тома.
Выключенные barriers / нет fsync в приложении → потеря данных при сбое.
Two-way синк без версионирования и единого времени → «съеденные» изменения.
Онлайн-`discard` на горячем пуле → хвосты латентности.
Миллионы мелких файлов в одном каталоге → катастрофический листинг/backup.
Смешение прав/владельцев между SMB и NFS без явного маппинга.

Мини-плейбуки

One-way публикация билда → edge-серверы

1. Сборка в `/srv/builds` (локальная ФС). 2) `rsync -az --delete` на edge. 3) Инвалидация CDN.

Bi-dir рабочая папка аналитиков

1. Syncthing/Unison, «версионирование N дней», конфликт — сохранять обе версии. 2) Квоты per-user. 3) Периодический offsite-бэкап.

DR каталога отчетов (WORM)

1. ZFS снапшоты по расписанию. 2) `send/recv` в изолированный хост с Object Lock/WORM. 3) Ежемесячный тест восстановления.

Итог

Надежная файловая подсистема — это правильная ФС + корректные режимы журналирования/барьеров + понятная модель блокировок, а эффективная синхронизация — это правильная топология (one-way/bi-dir), версионирование и проверенные инструменты. Фиксируйте решения в runbook-ах, автоматизируйте снапшоты/репликацию, измеряйте SLO и тестируйте отказовые сценарии — так данные останутся целыми, а операционные процессы предсказуемыми даже под пиковыми нагрузками.