File Systems and Synchronization

Brief Summary

A file system is a balance of integrity, performance, and operations. Synchronization is about a consistency model and conflict resolution, not just "copy files." We start with the requirements (p95 latency, RPO/RTO, load type), select the file system and protocol, configure logging and locks, set SLO, automate snapshots/versioning and use the correct synchronization tools.

Choosing a file system for the load

Universal Linux FS

ext4 is a stable workhorse. Options: 'noatime, nodiratime, discard (with caution), data = ordered'. Good for VM drives, shared directories, CI artifacts.
XFS - strong on large files/parallelism (media content, logs, DWH). Options: 'noatime, inode64'; for large files it is worth configuring 'reflink = 1' (clone).
ZFS - CoW, integrity check, snapshots/replica 'send/recv', ARC/L2ARC, ZIL/SLOG for sync. Excellent for backups, NAS, base pools with integrity requirement.
Btrfs - CoW, snapshots/compression/RAID in userspace; good under dev/test and edge, careful for OLTP without tuning.

Windows/Cross Platform

NTFS - ACL, ADS, reliable for SMB; 'DisableLastAccess' for performance.
exFAT - removable media, without rights and logging (not for production).

Settings that affect reliability and speed

Logging and barriers: 'data = ordered' (ext4 by default) - balance; 'data = journal' - safer, but slower; Verify that write barriers are enabled (or controller with BBU/PLP).
fsync/sync: critical threads (logs/transactions) must explicitly call 'fsync ()'; otherwise loss in case of accident is possible.
atime: 'relatime '/' noatime' reduces write pressure.
xattr/ACL-Enable if POSIX ACLs and security labels are required.
Block size/recordsize: ZFS'recordsize = 16K'for DB;' 1M'for large media.

Examples of mounting:

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

Network and Distributed File Systems

NFS/SMB (NAS approach)

NFSv3/v4: simple and fast; v4 gives locks and Kerberos ('sec = krb5p'). Do not rely on NFS for high-frequency "deep" fsync - better local disk + asynchronous unloading.
SMB 3. x: multichannel, encryption, AD integration. Enable signing/encryption on sensitive data.

Export NFS (minimum):


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

SMB (fragment):


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

Distributed FS

CephFS - POSIX over Ceph; good for horizontal scale, snapshots, quotas, metadata distributed.
GlusterFS - easy to start, replica/sharding, but neat with small files and p99.
Lustre/IBM Spectrum Scale - LDC/large files, demanding on network/operations.
9P (Virtio-fs) - for VM sharing, not for production loads with hard SLOs.

Recommendation: for OLTP/wallets - not network FS; use block volumes. For static content/common artifacts - NFS/SMB/object + CDN.

Locks, caching, and consistency

Advisory vs mandatory locks: Linux обычно advisory; SMB supports oplocks/leases, NFSv4 supports stateful locks.
Client caching: Aggressive caches speed up reading, but with multi-clients increase the risk of conflicts.

Consistency:

Strong (local FS, ZFS).
Close-to-open (NFS) - changes are visible when 'close ()/open ()'.
Eventual (some distributed/object scripts).
Hours: NTP/PTP; time drift breaks conflict-resolution and TTL.

Synchronizing: models and tools

Models

One-way (push/pull): publishing artifacts, uploading reports, offsite backup.
Two-way (bi-dir): collaboration; resolver conflict and versioning are required.
Hub-and-spoke: star through the central node/cluster (MinIO/S3 + agents).
Near-real-time vs batch: inotify/change logs vs periodic windows.

Tools

rsync is the de facto one-way standard; '--delete', '--partial', '--inplace' (caution).
rclone - S3/clouds, hash checking, server-side copy.
Unison - true bi-directional, conflict resolution.
Syncthing - p2p, versioning, convenient for work folders.
lsyncd - rsync trigger by inotify; near-real-time.
ZFS send/recv is the perfect sink of snapshots/increments (byte efficient).

rsync (one-way, static directory publishing):

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

Unison (bi-dir, profile):


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 over 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 replica (increment):

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

Versioning, snapshots and baskets

CoW snapshots (ZFS/Btrfs/CephFS): quick rollback points, min. invoices.
Application-level versioning (Nextcloud/Syncthing/object): convenient for users.
Recycle baskets on SMB/NFS: save from accidental deletion, but do not replace the backup.

Security and access

ACL and xattr: POSIX ACL, SID/ACE for SMB, uid/gid mapping.
Read/write through gateways: SFTP/HTTPS/WebDAV - when SMB/NFS cannot be opened outside.
Encryption: LUKS/ZFS native; in flight - Kerberos (NFSv4), SMB encryption, TLS for gateways.
PII/compliance: ball segmentation, strict rights masks, access audits, WORM where needed unchangeable.

Observability, SLO and alerts

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

SLO (examples):

NFS ball CI: p95 'open '/' read' ≤ 3-5 ms, availability ≥ 99. 95%.
SMB reports: p95 directory listing ≤ 100 ms when ≤ 10k files/dir.
ZFS backup pool: p99 write ≤ 10 ms, 100% snapshot success, RPO ≤ 15 min (increments).

Alerts:

Pool filling> 80/90/95%, 'EIO' growth, snapshots lag, hit-ratio drop, oplock-break frequent.

Product patterns (iGaming/fintech)

Static (icons/previews/provider directories): publishing via rsync → CDN; store the original source in a versioned object.
Logs and "raw" events: write locally (XFS/ext4) → batch unload (rclone → S3/MinIO).
Reporting and PII: SMB with encryption and strict ACLs; periodic offsite export (ZFS send/recv) with WORM on the receiving side.
Dev environments and capturing artifacts: NFS/SMB for sharing; for heavy bases - block volumes + snapshots.
Content collaboration: Syncthing/Nextcloud with versioning and quotas.

Implementation checklist

Defined data classes (hot/cold/PII), RPO/RTO and SLO.
Selected file system: ext4/XFS/ZFS with correct options (noatime, barriers, recordsize).
If NAS: Encrypted/Signed NFSv4/SMB, ACL, Kerberos/AD.
Snapshots/versioning/Recycle Bins - Configured and verified by recovery.
Bruise tool for the task: rsync (one-way), Unison/Syncthing (bi-dir), rclone (cloud), ZFS send/recv (backup/DR).
Monitoring of FS/network/operations, burn-rate SLO, ENOSPC/EIO/oplock alerts.
Documentation: Runbook conflicts, fsync rules, naming/path length/encoding policy.
Tests: load profiles (small/large files), cut scripts (disconnection, editing conflict).

Common errors

Shared critical transaction netball (OLTP) instead of local block volume.
Disabled barriers/no fsync in the application → data loss on failure.
Two-way synk without versioning and a single time → "eaten" changes.
Online 'discard' on hot pool → latency tails.
Millions of small files in one directory → catastrophic listing/backup.
Mix rights/owners between SMB and NFS without explicit mapping.

Mini playbooks

One-way publishing build → edge servers

1. Assembly in '/srv/builds' (local file system). 2) `rsync -az --delete` на edge. 3) CDN disability.

Bi-dir Analyst Working Folder

1. Syncthing/Unison, "versioning N days," conflict - save both versions. 2) Per-user quotas. 3) Periodic offsite backup.

Report Catalog DR (WORM)

1. ZFS snapshots on a schedule. 2) 'send/recv' to an isolated host with Object Lock/WORM. 3) Monthly recovery test.

Result

A reliable file subsystem is the correct file system + correct logging/barrier modes + an understandable blocking model, and effective synchronization is the correct topology (one-way/bi-dir), versioning and proven tools. Capture solutions in runbooks, automate snapshots/replication, measure SLOs and test failure scenarios - this way data will remain intact and operational processes predictable even at peak loads.