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

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

Файлова система - це баланс цілісності, продуктивності та операцій. Синхронізація - це про модель узгодженості і вирішення конфліктів, а не тільки «скопіювати файли». Починаємо з вимог (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 - простий в старті, репліка/шардинг, але акуратно з маленькими файлами і p99.
Lustre/IBM Spectrum Scale - НРС/великі файли, вимогливі до мережі/операцій.
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 і тестуйте відмовні сценарії - так дані залишаться цілими, а операційні процеси передбачуваними навіть під піковими навантаженнями.