Надійні дескриптори SMB у ZFS: чому копіювання/переміщення здається дивним

Ментальна модель: що насправді означає «надійний»

Почнімо з прямої заяви: SMB — це не «просто файловий ввід/вивід». Це stateful-протокол із серверною пам’яттю про те, що робить клієнт.
Надійні дескриптори — частина цієї пам’яті.

В SMB2/SMB3 клієнт відкриває файл і отримує дескриптор. Цей дескриптор репрезентує живий стан: блокування, режими доступу, блочні
локи на байтах, права кешування і іноді lease (структурована обіцянка щодо кешування і когерентності). Якщо мережа зривається,
раніше клієнт втрачає дескриптор. Програми отримують «файл не знайдено» або «мережеве ім’я більше недоступне», і всі звинувачують
сховище.

Надійні дескриптори вирішують цю проблему: сервер може зберігати стан відкриття певний час, щоб клієнт міг перепідключитися й «відтребувати»
відкриття. Перепідключення може статися після TCP reset, проблем зі Wi‑Fi або переведення ноутбука в режим сну. Це функція надійності.
Компроміс у тому, що сервер має зберігати й перевіряти більше стану й бути обережним під час перейменувань/переміщень, поки дескриптори
існують.

Тепер додайте ZFS. ZFS дуже добре зберігає консистентність на диску й забезпечує стабільну ідентичність об’єктів. SMB добре зберігає
консистентність відкритих файлів під час перепідключень. Разом ви отримуєте коректність. Але також отримаєте видимі стрибки латентності
в місцях, де користувачі Windows думають: «чому move поводиться як copy?»

Чому копіювання/переміщення виглядає дивно на SMB поверх ZFS

1) «Переміщення» — це тільки перейменування, якщо сервер може зробити атомарний rename

На локальному NTFS переміщення в межах файлової системи зазвичай — це метаданова операція rename: швидка, атомарна і не торкається даних.
На SMB Explorer просить сервер зробити rename (SMB2 SET_INFO / FileRenameInformation). Якщо перейменування в межах того самого шару й
сервер може відобразити це на простий rename, воно буде швидким.

Але якщо «переміщення» перетинає межі, які сервер вважає неатомарними — різні шари, різні файлові системи, окремо змонтовані датасети або
шлях, що потрапляє під іншу політику VFS — сервер може відповісти «не можу зробити як rename». Тоді клієнт повертається до copy+delete.
Це перше джерело «дивності».

2) Надійні дескриптори змушують сервер обережніше ставитися до перейменувань і видалень

Якщо файл відкритий із надійним дескриптором і клієнт може перепідключитися, щоб продовжити запис, сервер повинен зберегти семантику:
дескриптор має й далі вказувати на той самий об’єкт файлу після перейменування. Це здійсненно, якщо сервер відстежує file IDs надійно.
Але це змінює профіль витрат. Операції, які раніше були «просто перейменуванням запису», тепер вимагають:

• Оновлення таблиць надійних дескрипторів і стану розриву leases
• Валідації режимів спільного доступу для нового імені/місця
• Забезпечення видимості та когерентності перейменування для інших клієнтів
• Можливого примусового розриву leases/oplocks, щоб інші клієнти скидали кеші

Це не безкоштовно. Якщо сервер завантажений або метадані I/O повільний, rename може зайняти стільки часу, що Explorer здається «копіює».
UI — не аналізатор протоколу; це відчуття плюс індикатор прогресу.

3) «Миттєве переміщення» з одночасним затриманим видаленням зазвичай — це відкладене видалення або утримання дескрипторів

Інший дивний випадок: ви перемістили папку, вона з’явилася в місці призначення, але деякий час іще видна в джерелі. Є кілька реальних причин:

• Кешування записів директорій на клієнті (Explorer надто оптимістичний).
• Відкриті дескриптори, що перешкоджають видаленню; сервер позначає на видалення при закритті.
• Снапшоти або утримання, які змушують дані зберігатися, навіть якщо жива простір-іменна змінилася (іменна зміна; блоки залишаються).
• Переміщення між датасетами, що реалізується як copy+delete; видалення чекає на закриття дескрипторів.

4) Межі датасетів ZFS перетворюють rename на копіювання, навіть якщо шляхи виглядають «поруч»

Датасети ZFS — не просто директорії з гарною назвою. Це окремі файлові системи з власними точками монтування, властивостями і іноді різним
recordsize, компресією, макетом xattr та поведінкою ACL. Переміщення між датасетами не є атомарним. SMB-сервер не може виконати
одиночне файлове перейменування, коли джерело й призначення — різні файлові системи.

Це означає, що «move» в Explorer стає «copy, потім delete». Користувачі не знають (і їм байдуже), що таке датасет. Вони бачать операцію,
яка раніше була миттєвою, а тепер зайняла хвилини. Ви або навчите їх, або спроєктуєте шари так, щоб межі датасетів були непомітні для їхніх робочих процесів.
Вибирайте. Одне з двох станеться.

5) SMB-метадані болісно говіркі; метадані ZFS можуть бути дорогими під навантаженням

Копіювання дерева директорій — це не тільки дані. Це фестиваль метаданих: create, set security, set timestamps, set attributes, set
alternate data streams, query info, open/close. Надійні дескриптори й leases додають переходи станів до цього фестивалю. ZFS під
сильним синхронним навантаженням або з обмеженими метаданними IOPS зробить цей фестиваль схожим на повільну ходу.

Короткий жарт №1: Надійні дескриптори — як зберегти квиток із парковки після виїзду з гаража — корисно, якщо не вимагається, щоб ви також
тримали там машину назавжди.

Цікаві факти й трохи історії

1. SMB2 з’явився з Windows Vista/Server 2008 і значно зменшив «балакучість SMB1», групуючи й пропускаючи операції.
2. Надійні дескриптори з’явилися в SMB2.1 (епоха Windows 7/Server 2008 R2), щоб переживати транзитні розриви без ретраїв на рівні додатка.
3. SMB3 додав «persistent handles», головно для безперервно доступних шарів у кластерах; вони сильніші за «durable».
4. Opportunistic locks (oplocks) існували ще до SMB2; SMB2+ узагальнив їх у leases з чіткішою семантикою.
5. Індикатор прогресу Windows Explorer — не аналізатор протоколу; часто неправильно маркує copy vs move, коли відбуваються fallback-и.
6. Переіменування в ZFS атомарне в межах датасету, але не через датасети; тоді це вищого рівня copy+unlink.
7. Снапшоти ZFS не «заморожують» живу файлову систему; вони зберігають старі блоки. Видалення після снапшоту може стати роботою з вивільнення простору пізніше.
8. Samba реалізує надійні дескриптори в просторі користувача; продуктивність і семантика залежать від поведінки kernel VFS, підтримки xattr і вибраних vfs-модулів.
9. SMB використовує file IDs для ідентифікації файлів поза іменами. Сервери, що можуть надати стабільні inode-подібні ID, роблять durable-семантику розумнішою.

Надійні дескриптори проти leases/oplocks і «persistent» дескрипторів

Надійні дескриптори

Надійний дескриптор — це про перепідключення. Сервер зберігає стан після розриву, щоб клієнт міг його відтребувати. Сервер
визначає, як довго зберігати і за яких умов. Надійні дескриптори поширені в сучасних стеках SMB.

Leases (і oplocks)

Leases — це про кешування. Вони дозволяють клієнту кешувати читання, запис і метадані з меншими раундами. Коли інший
клієнт запитує конфліктний доступ, сервер «ламає» lease і клієнт скидає/скидає кеші. Переривання lease може виглядати як випадкові паузи
під час copy/move, бо сервер змушує узгодженість.

Persistent handles

Persistent handles — це варіант «не втрачай мій дескриптор, навіть якщо сервер відмовив» — призначені для безперервно доступних шарів у кластерах.
Якщо ви не маєте кластера, призначеного для цього, очікування persistent-революцій може принести проблеми.

Практичний висновок: надійні дескриптори зберігають коректність при перепідключенні; leases роблять усе швидким, поки не треба бути коректним.
Дивна поведінка копіювання/переміщення часто виникає на переході між цими режимами.

Парафраз — Richard Cook: «Складні системи відмовляють складно; оператори повинні постійно зіставляти, як робота насправді виконується.»

Механіка ZFS, що має значення: IDs, txgs, xattrs, snapshots

Стабільна ідентичність файлу: inode-подібна поведінка й SMB file IDs

Клієнти SMB виграють, коли сервер може надати стабільні file IDs, щоб «той самий об’єкт, нова назва» залишався істинним після rename.
ZFS має сильну внутрішню ідентичність об’єктів. Samba (або ваш SMB-стек) відображає це на SMB file IDs. Якщо це відображення стабільне,
відновлення надійних дескрипторів після перейменування безпечніше. Якщо ні — сервер стає консервативним: більше перевірок, більше розривів,
більше fallback-ів.

Transaction groups (txgs) і синхронна поведінка

ZFS групує зміни в transaction groups. Багато дрібних метаданих під час копіювання директорії можуть накопичуватися і тоді зливатися.
Якщо ваша робота викликає синхронну семантику (явний sync або налаштування SMB, що її передбачають), ви можете отримати періодичні
затримки, коли система чекає на intent log і commit txg.

Це одна з причин, чому «копіювання плавне, а переміщення стрибає»: операції move можуть створювати сплески метаданих і послідовності rename/unlink,
що по-іншому влучають у синхронні точки, ніж прості послідовні записи.

xattrs і alternate data streams

Windows використовує alternate data streams (ADS). SMB-сервери часто реалізують ADS через розширені атрибути. На ZFS xattrs можуть зберігатися
по-різному (залежить від реалізації), і метадані дрібних файлів може перетворитися на багато випадкових I/O під тиском пам’яті.
Копіювання з Windows часто включає security descriptors, zone identifiers та інші метадані, які «мають бути дешевими», поки не стануть дорогими.

Снапшоти: переміщення відбулося, але простір не повернувся

Користувачі питають «Я перемістив, чому пул ще повний?» — Снапшоти. Переміщення в межах одного датасету може просто перейменувати записи; простір не змінюється.
Copy+delete між датасетами може звільнити місце в джерелі, але якщо на джерелі є снапшоти, блоки лишаються зафіксованими.
З точки зору ємності, «видалити» означає «позначити як вільне в живому дереві, але блоки ще посилаються снапшотом». Це коректно. Це також вводить в оману,
коли ви спостерігаєте вільний простір як біржовий індикатор.

Режими відмов, що виглядають як «SMB повільний» але ними не є

Шторм перейменувань, що викликає розриви leases

Великі переміщення дерев директорій — це шторм перейменувань. Якщо інші клієнти переглядають ці директорії, сервер мусить підтримувати когерентні
подання. Розриви leases каскадують. Ваше «просте переміщення» стає вправою в координації між багатьма клієнтами.

Антивірус і індексація вмісту перетворюють метадані на латентність

На Windows Defender (або корпоративні AV) люблять нові файли. Копіювання створює нові файли. Move-as-copy створює нові файли. Клієнт буде їх
читати, хешувати і іноді повторно відкривати. Це збільшує кількість SMB open/close, що взаємодіє з таблицями надійних дескрипторів і режимами спільного доступу.
Сховище отримує докір від захисної ентузіазму команди безпеки.

Тиск ARC і ампліфікація дрібних I/O

Копіювання багатьох дрібних файлів — це навантаження метаданих і дрібних I/O. Якщо ARC під тиском, система починає виконувати реальні дискові читання
для метаданих, які інакше були б у кеші. Латентність зростає. Латентність SMB зростає. Explorer оголошує, що переміщення «обчислює…» вічно.

Переміщення між шарами: плата за чисті адміністративні межі в UX

Адміністратори люблять кілька шарів. Користувачі люблять «воно перемістилось миттєво». Ці бажання часто взаємовиключні. Переміщення між шарами
зазвичай не може бути серверним rename. Клієнт копіює й видаляє — це правильно, але не швидко.

Практичні завдання: команди, виходи й рішення

Ось перевірки, які я запускаю, коли хтось каже «SMB moves дивні на ZFS». Кожне завдання містить: команду, що означає вихід, і рішення, яке на її основі приймають.

Завдання 1: Підтвердити межі датасетів і точки монтування

cr0x@server:~$ zfs list -o name,mountpoint -r tank/smb
NAME               MOUNTPOINT
tank/smb           /tank/smb
tank/smb/users     /tank/smb/users
tank/smb/projects  /tank/smb/projects
tank/smb/archive   /tank/archive

Значення: tank/smb/archive змонтований в іншому місці. «Переміщення» з /tank/smb/projects до /tank/smb/archive перетинає файлові системи.

Рішення: Якщо користувачі регулярно переміщують між цими шляхами, або об’єднати в один датасет, або прийняти copy+delete-поведінку (і повідомити користувачам).

Завдання 2: Перевірити, чи джерело й призначення — одна й та сама файловая система з погляду ядра

cr0x@server:~$ stat -f -c '%T %m' /tank/smb/projects /tank/archive
zfs /tank/smb/projects
zfs /tank/archive

Значення: Обидва — ZFS, але це не означає один датасет. stat -f не диференціює датасети; просто каже «zfs».

Рішення: Використовуйте Завдання 1 плюс карту шарів. Не припускайте, що «той самий пул» означає «та сама файловая система».

Завдання 3: Зіставити SMB-шари з шляхами файлової системи (Samba)

cr0x@server:~$ testparm -s 2>/dev/null | sed -n '/^\[users\]/,/^\[/{/path =/p}'
	path = /tank/smb/users

Значення: Шара [users] вказує на /tank/smb/users. Зробіть це для обох шар, задіяних у «переміщенні».

Рішення: Якщо переміщення перетинає шари, очікуйте copy+delete на клієнті, якщо тільки ви не використовуєте серверні функції копіювання і клієнт їх не підтримує.

Завдання 4: Спостерігати живі SMB-сесії й відкриті файли

cr0x@server:~$ smbstatus --shares --processes
Service      pid     Machine       Connected at                     Encryption   Signing
users        21408   10.20.30.44    Tue Dec 26 09:10:12 2025 UTC     -            -
projects     22119   10.20.30.44    Tue Dec 26 09:11:05 2025 UTC     -            -

Значення: Той самий клієнт підключений до кількох шар. Переміщення між шарами ймовірно copy+delete.

Рішення: Якщо це частий робочий процес, представте один спільний корінь шару, який триматиме звичні переміщення в межах одного шару і датасету.

Завдання 5: Виявити поведінку надійних дескрипторів і lease у логах Samba

cr0x@server:~$ grep -E 'durable|lease|oplock' /var/log/samba/log.smbd | tail -n 8
[2025/12/26 09:17:41.231112,  3] smbd/smb2_oplock.c:3177(smbd_smb2_request_process_break)
  Sending break for lease key 9c3c2b0d...
[2025/12/26 09:17:41.245891,  3] smbd/smb2_server.c:4041(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: idx[1] status[STATUS_OPLOCK_BREAK_IN_PROGRESS]

Значення: Відбуваються розриви lease. Це сервер змушує клієнтів скидати кеші, часто під час штормів перейменувань.

Рішення: Якщо розриви lease корелюють з «дивним переміщенням», зменшіть одночасну активність у директоріях під час міграцій або заплануйте їх поза піком.

Завдання 6: Перевірити властивості датасету ZFS, що впливають на поведінку метаданих SMB

cr0x@server:~$ zfs get -H -o name,property,value atime,xattr,acltype,casesensitivity,recordsize,sync tank/smb/projects
tank/smb/projects	atime	off
tank/smb/projects	xattr	sa
tank/smb/projects	acltype	posixacl
tank/smb/projects	casesensitivity	mixed
tank/smb/projects	recordsize	1M
tank/smb/projects	sync	standard

Значення: xattr=sa може бути корисним для метаданих-інтенсивних навантажень; recordsize=1M підходить для великих файлів, але не вирішує проблеми дрібних файлів.

Рішення: Якщо ви бачите інтенсивний трафік ADS/xattr і випадкові I/O, перевірте стратегію xattr і розгляньте датасет, налаштований під дрібні файли (і тримайте переміщення в його межах).

Завдання 7: Перевірити тиск снапшотів, коли «видалення не звільнило простір»

cr0x@server:~$ zfs list -t snapshot -o name,used,refer,mountpoint -r tank/smb/projects | head
NAME                                USED  REFER  MOUNTPOINT
tank/smb/projects@daily-2025-12-25   118G  2.4T   -
tank/smb/projects@daily-2025-12-26   6.1G  2.5T   -

Значення: Снапшоти посилаються на значні обсяги. Видалення/переміщення файлів не звільнить ці блоки, поки снапшоти не видалені.

Рішення: Якщо проблема в ємності, налаштуйте політику зберігання снапшотів або перемістіть дані в датасет без довгоживучих снапшотів (зважено).

Завдання 8: Спостерігати txg і затримки I/O під час операції

cr0x@server:~$ iostat -x 2 5
Linux 6.6.44 (server) 	12/26/2025 	_x86_64_	(32 CPU)

avg-cpu:  %user %nice %system %iowait  %steal   %idle
          12.1  0.0     6.8     9.7     0.0    71.4

Device            r/s     w/s   rkB/s   wkB/s  await  svctm  %util
nvme0n1         215.0   480.0  8200.0 51200.0   8.40   0.35   24.0
sdg             120.0   900.0  1400.0 18000.0  38.20   1.10   95.0

Значення: Один пристрій завантажений до високого %util і має високе await. Саме там чекає ваше «rename».

Рішення: Якщо метадані лягають на повільні vdev-и, виправте розкладку vdev, додайте спеціальні класи розподілу (де можливо) або зменшіть метадані-важкі операції в піковий час.

Завдання 9: Перевірити ефективність ARC і його тиск (Linux)

cr0x@server:~$ arcstat 2 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
09:20:11  12K  3.1K     25   510   16   2.6K   84     0    0   92G   110G
09:20:13  15K  5.9K     39   820   14   5.1K   86     0    0   92G   110G
09:20:15  14K  6.2K     44   900   14   5.3K   86     0    0   92G   110G

Значення: Відсоток промахів високий і переважно prefetch-промахи. Ви виконуєте випадкову роботу з метаданими/дрібними файлами, що не залишається гарячим.

Рішення: Якщо це корелює зі штормами копіювань/переміщень, додайте RAM, зменшіть паралелізм або перемістіть метадані на швидший носій, якщо платформа це підтримує.

Завдання 10: Підтвердити, чи операція — це rename або copy+delete з боку клієнта (Windows через серверні логи)

cr0x@server:~$ grep -E 'rename|unlink|NT_STATUS|SET_INFO' /var/log/samba/log.smbd | tail -n 10
[2025/12/26 09:21:44.101220, 10] smbd/smb2_trans2.c:3920(smbd_smb2_setinfo_file)
  SMB2_SETINFO_FILE: FileRenameInformation
[2025/12/26 09:21:44.141109, 10] smbd/close.c:871(close_normal_file)
  closed file users/alice/report.xlsx (numopen=0) NT_STATUS_OK

Значення: Ви бачите FileRenameInformation, отже принаймні частина переміщення — справжнє перейменування.

Рішення: Якщо UI показує «копіювання», але логи — rename, зосередьтеся на латентності метаданих/розривах lease, а не на пропускній здатності даних.

Завдання 11: Перевірити опції шару, що змінюють поведінку sync/durability

cr0x@server:~$ testparm -s 2>/dev/null | grep -E 'strict sync|sync always|durable handles|kernel oplocks|oplocks|leases'
	kernel oplocks = no
	oplocks = yes
	leases = yes
	strict sync = yes

Значення: strict sync = yes може примушувати синхронну семантику для певних операцій, збільшуючи латентність при метаданих-штормі.

Рішення: Не вимикайте strict sync сліпо. Рішення приймайте для кожного шару залежно від критичності даних. Для домашніх каталогів — можливо; для облікових даних — навряд.

Завдання 12: Виявити «переміщення стало копією» через несподіваний об’єм записів

cr0x@server:~$ zpool iostat -v tank 2 3
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        88.2T  21.5T    220   1600   18M   220M
  raidz2-0  40.1T  10.2T    110    900   10M   120M
    sdg         -      -     30    260  2.5M    34M
    sdh         -      -     25    230  2.1M    30M
  raidz2-1  48.1T  11.3T    110    700  8.0M   100M
    sdi         -      -     28    210  2.0M    29M
    sdj         -      -     26    190  1.8M    27M

Значення: Переміщення в межах датасету не повинно генерувати постійні сотні МБ/с записів. Якщо так — це копіювання.

Рішення: Перепроєктуйте межі шару/датасету. Якщо користувачі мають переміщати між датасетами, плануйте пропускну здатність і AV-накладні витрати; не обіцяйте швидкість rename.

Завдання 13: Перевірити тиск переліку директорій (чи робимо ми мільйони LOOKUP?)

cr0x@server:~$ nfsstat -c 2>/dev/null || true
nfsstat: NFS not running

Значення: Не NFS — добре. Для тиску переліків SMB доведеться покладатися на логи SMB, perf counters і трасування системних викликів.

Рішення: Якщо не можете інструментувати SMB належно, підвищте рівень логів Samba коротко для одного IP-клієнта й зафіксуйте поведінку rename/copy.

Завдання 14: Трасувати системні виклики rename/unlink під час «move» (Linux-сервер)

cr0x@server:~$ sudo strace -f -p $(pidof smbd | awk '{print $1}') -e trace=rename,renameat,unlink,unlinkat -s 128 -tt -o /tmp/smbd.rename.trace & sleep 5; tail -n 5 /tmp/smbd.rename.trace
09:23:10.118023 renameat(AT_FDCWD, "/tank/smb/projects/Q4/budget.xlsx", AT_FDCWD, "/tank/smb/projects/Q4-archive/budget.xlsx") = 0
09:23:10.118771 unlinkat(AT_FDCWD, "/tank/smb/projects/Q4/tmp~budget.xlsx", 0) = 0

Значення: Ви бачите реальні виклики renameat. Це вказує, що серверне перейменування відбувається — повільність імовірно через блокування/розриви lease або метадані I/O.

Рішення: Якщо бачите об’єм open/read/write замість перейменувань, це copy+delete. Тоді спочатку виправляйте проблему меж.

Завдання 15: Виявити видалення, заблоковане відкритими дескрипторами (Samba)

cr0x@server:~$ smbstatus --locks | head -n 12
Locked files:
Pid    Uid   DenyMode   Access      R/W        Oplock           SharePath   Name   Time
22119  1050  DENY_NONE  0x120089    RDONLY     EXCLUSIVE+BATCH  /tank/smb/projects  Q4/budget.xlsx  Tue Dec 26 09:23:44 2025

Значення: Клієнт має oplock/lease (відображено як oplock). Видалення або переміщення можуть потребувати розриву; якщо клієнт повільно відповідає, ви чекаєте.

Рішення: Якщо один клієнт тримає блокування і блокує операції, зверніться до цього клієнта (сплячі ноутбуки, застарілі додатки) перед налаштуванням сховища.

Швидкий план діагностики

Коли «переміщення» виглядає як «копіювання», не починайте з зміни налаштувань ZFS. Почніть з визначення, яка операція реально відбувається.
Ось порядок, що зекономить час.

Перш за все: це rename чи copy+delete?

• Перевірте шляхи шарів і межі датасетів (Завдання 1, Завдання 3).
• Спостерігайте за стійким обсягом записів під час «переміщення» (Завдання 12).
• Шукайте SMB-виклики rename у логах або трасуйте системні виклики (Завдання 10, Завдання 14).

Якщо це copy+delete: припиніть звинувачувати надійні дескриптори. Ваша архітектура змусила fallback.

По-друге: якщо це rename, у чому затримка?

• Шукайте розриви lease/oplock і STATUS_OPLOCK_BREAK_IN_PROGRESS (Завдання 5).
• Перевірте заблоковані видалення або відкриті дескриптори (Завдання 15).
• Корелюйте з дисковою латентністю/IO wait (Завдання 8).

Якщо це розриви lease: зменшіть одночасність, уникайте масових перейменувань у піковий час і розгляньте зміни в розкладці шарів.

По-третє: чи метадані I/O — вузьке місце?

• Перевірте відсотки промахів ARC (Завдання 9).
• Валідуйте властивості датасету під навантаження (Завдання 6).
• Переконайтеся, що снапшоти не маскують очікування звільнення простору (Завдання 7).

Якщо це метадані: виправлення — швидші метадані, більше пам’яті, менше дрібних файлів або краще планування — рідко «вимкнути надійні дескриптори».

Три короткі корпоративні історії

Інцидент: неправильне припущення («переміщення завжди — це rename»)

Середня компанія мала чисту таксономію зберігання: по одному датасету ZFS на відділ, по одній SMB-шарі на датасет, акуратні квоти,
акуратні снапшоти. Файловий сервер був здоровим і нудним — поки у фінансів не настав кінець кварталу. Раптом «переміщення» папок в архів
зайняло години. Квитки в службу підтримки множилися, і хтось оголосив пул ZFS «зношеним», бо Windows писав «Підготовка до переміщення…».

Неправильне припущення було просте: вони вважали, що переміщення в межах «того самого сервера» — це rename. Але архів був іншою шарою
й іншим датасетом. Windows робив copy+delete. Антивірус сканував нові файли. Фінансові інструменти повторно відкривали їх.
SMB-сервер робив саме те, що мав: примушував дотримуватися режимів шарів і зберігав відкриття надійними під час транзитних розривів.

SRE на виклику довів це, спостерігаючи за пропускною здатністю записів пулу під час «переміщення» і глянувши логи Samba на предмет rename-викликів.
Їх майже не було. Це був шторм копіювань. Водночас снапшоти на джерелі означали, що навіть після фази видалення простір не повернувся.
Користувачі бачили повільне переміщення і невідновлену ємність — і вирішили, що «зберігання бреше».

Виправлення не було прапором налаштування. Вони створили один корінь шару з підкаталогами для відділів в межах одного датасету для робочих
процесів, які потребували швидких переміщень. Вони зберегли окремі датасети позаду для політик снапшотів/ретеншену, але перестали експонувати
межі датасетів як окремі шари для щоденних користувачів. Квартальний кінець знову пройшов тихо. Файловий сервер повернувся до нудного стану —
а це найкраща похвала для операцій.

Оптимізація, що дала зворотний ефект: «давайте зробимо ще надійніше»

Інша організація постраждала від ноутбуків, що часто засинали під час копіювання. Вони дізналися про надійні дескриптори й вирішили,
що потрібно підвищити «безпеку» всюди. Вони ввімкнули strict sync і поводилися з SMB-сервером як з базою даних. Ніхто не поцікавився,
яке навантаження насправді: здебільшого дрібні файли Office, трохи CAD і величезні дерева директорій.

Результат показав дивний патерн: копіювання спочатку було гарним, але потім з’являлися періодичні паузи. Переміщення в межах датасету були
«здебільшого миттєві», але іноді застрягали на десятки секунд. Користувачі помічали зависання під час масової реорганізації папок, що
інтенсивно працює з метаданими й перейменуваннями. Кожна пауза відповідала сплеску синхроноподібних метаданих і купі розривів lease, оскільки
кілька клієнтів переглядали ті самі дерева.

Команда зберігання переслідувала диски. Мережники шукали MTU. Windows-команда шукала оновлення Explorer. Справжнім питанням була політика:
вони наклали «базову надійність» на загальний файловий шар. Коректність майже не покращилася (SMB і так мав механізми надійності), але латентність
погіршилася. Вони відкотили strict sync на загальних шарах, залишили його лише там, де бізнес вимагав, і перемістили критичні дані на шар із
чіткими очікуваннями та вікнами обслуговування.

Надійні дескриптори не були лиходієм. Лиходій — у тому, щоб уявляти, що всі дані мають однакові семантики запису. Це не так.

Нудна, але правильна практика, що врятувала: планування меж і вікна змін

Компанія з великою інженерною організацією мала щотижневу «садівничу» роботу по файловій системі: очищення, архівування, реорганізація.
Вони навчились (не одразу) що масові перейменування в робочий час породжують шторм розривів lease і злих користувачів. Тож вони зробили дві нудні речі.

По-перше, вони спроєктували шари так, щоби найпоширеніші переміщення залишалися в межах датасету. «Активний проект» і «архів проекту» жили в одному
датасеті з кордоном директорії, а не як окремі датасети. Retention оброблявся снапшотами й політикою реплікації, а не тим, що користувачі переміщують
між файловими системами.

По-друге, вони планували будь-яку міграцію між датасетами на вікно, заздалегідь повідомляли й обмежували швидкість. Вони використовували контрольований
інструмент на сервері (не Explorer drag-and-drop), щоб вимірювати поведінку і уникати «thundering herd» ефектів від десятків клієнтів.

Одного тижня мережева зміна спричинила короткі розриви на поверсі. Ноутбуки перепідключилися. Надійні дескриптори зробили свою роботу. Робота міграції
продовжилася без корупції. Користувачі ледве помітили. Постмортем був короткий і нудний — а це найвища похвала в операціях.

Короткий жарт №2: якщо ви хочете драйв, відкривайте нічний клуб. Якщо хочете надійність — керуйте файловим сервером.

Поширені помилки: симптом → корінь → виправлення

1) Симптом: «Переміщення в тому ж сервері так само повільне, як копіювання»

Корінь: Переміщення перетинає SMB-шари або датасети ZFS, тож воно не може бути rename; Windows робить copy+delete.

Виправлення: Розмістіть джерело та призначення в одному шарі й датасеті для звичних робочих процесів; або прийміть, що це копія, і підберіть систему під неї.

2) Симптом: «Переміщення зависає на 99%»

Корінь: Відкриті дескриптори або відкладене видалення; Explorer чекає на завершення видалень/метаданих, поки інший клієнт тримає lease/oplock.

Виправлення: Використайте smbstatus --locks щоб знайти блокувальників; порвіть залежність (закрийте додаток, виправте сплячі ноутбуки, зменшіть слідкувачі директорій).

3) Симптом: «Папку перемістили, але вона все ще з’являється в старому місці»

Корінь: Кешування на клієнті, кеш переліку директорій або затримане оновлення через розриви lease.

Виправлення: Примусьте оновлення, підтвердьте простір імен на сервері через ls. Якщо на сервері консистентно — це кеш клієнта. Якщо ні — перевірте логи SMB на помилки.

4) Симптом: «Ми видалили терабайти, а простір не повернувся»

Корінь: Снапшоти утримують блоки; видалення лише прибирає живі посилання.

Виправлення: Перегляньте used/refer снапшотів; налаштуйте політику зберігання або перемістіть дані в датасет з відповідною політикою снапшотів.

5) Симптом: «Випадкові паузи під час копіювання/переміщення багатьох файлів»

Корінь: Розриви lease/oplock; затримки метаданих I/O; тиск ARC; синхронні політики метаданих.

Виправлення: Корелюйте логи Samba з iostat і ARC-метриками. Зменшіть паралельні операції по дереву і спочатку виправте затримку зберігання.

6) Симптом: «Після Wi‑Fi збою додаток продовжує зберігати, але rename не вдається»

Корінь: Перепідключення надійного дескриптора відбулося, але наступне перейменування конфліктує з режимами спільного доступу або іншим дескриптором у місці призначення.

Виправлення: Перевірте відкриття на джерелі й призначенні; розгляньте зміни робочого процесу (зберегти у тимчасовий файл, потім атомарно перейменувати) і переконайтеся, що сервер підтримує стабільні file IDs.

7) Симптом: «Копіювання швидке, а переміщення повільне (в межах того ж датасету)»

Корінь: Переміщення викликає pattern rename/unlink, що викликає більше розривів lease і оновлень метаданих; копіювання може ефективно стримувати дані.

Виправлення: Виміряйте розриви lease і латентність метаданих; плануйте великі реорганізації і уникайте їх під час, коли багато клієнтів переглядають те саме дерево.

8) Симптом: «Robocopy /Z працює, Explorer падає»

Корінь: Різна поведінка клієнтів. Robocopy використовує restartable mode і інші semantics повторів; Explorer — орієнтований на UI і іноді чутливіший до сприйманих помилок.

Виправлення: Для міграцій використовуйте надійні інструменти (Robocopy, серверні інструменти) з явними прапорами; розглядайте Explorer як зручний інструмент, але не як систему міграції.

Контрольні списки / покроковий план

План проєктування: запобігти сюрпризам «переміщення стало копією»

1. Складіть список топ‑5 користувацьких робочих процесів, що включають реорганізацію даних (переміщення/перейменування).
2. Переконайтесь, що ці робочі процеси залишаються в межах одного SMB-шару, коли це можливо.
3. Переконайтесь, що ці робочі процеси залишаються в межах одного датасету ZFS, якщо «миттєве переміщення» є вимогою.
4. Використовуйте датасети для політик (snapshots/quotas/replication) там, де це не порушує робочі процеси — або приховуйте межі за одним коренем шару.
5. Визначте, які шари потребують строгих семантик durable, а які — пропускної здатності/низької латентності; документуйте рішення.

Операційний чекліст: коли користувачі скаржаться на дивність move/copy

1. Запитайте: шлях джерела, шлях призначення, приблизна кількість файлів, типи файлів і чи інші користувачі переглядали дерево.
2. Перевірте, чи воно перетинає шари/датасети (Завдання 1, Завдання 3).
3. Перевірте, чи пік записів пулу під час «переміщення» (Завдання 12).
4. Якщо rename: перевірте розриви lease і блокування (Завдання 5, Завдання 15).
5. Корелюйте з дисковою латентністю та тиском ARC (Завдання 8, Завдання 9).
6. Перевірте снапшоти, якщо «видалення не звільнило простір» (Завдання 7).
7. Лише після збору доказів змінюйте один параметр за раз (опція шару, планування, розкладка датасету).

Чекліст для міграцій: переміщення даних між датасетами без драми

1. Переважно використовуйте серверні інструменти під час вікна змін; не покладайтеся на Explorer drag-and-drop для терабайтів.
2. Обмежуйте паралельність; переміщення дрібних файлів масштабуються погано із «більше потоків», коли метадані — вузьке місце.
3. Заморозьте або координуйте політику AV/індексації, якщо можете (або принаймні передбачте накладні витрати).
4. Вимірюйте: затримки IOPS, розриви lease, кількість відкритих дескрипторів під час переміщення.
5. Майте план відкату: якщо шторм lease впливає на користувачів, зупиніть завдання чисто і відновіть пізніше.

FAQ

1) Чи є надійні дескриптори функцією ZFS?

Ні. Надійні дескриптори — це функція протоколу SMB, реалізована SMB‑сервером (часто Samba на Unix‑подібних системах). ZFS впливає на те,
наскільки добре сервер може відобразити стабільну ідентичність файлу і наскільки швидко виконуються операції з метаданими.

2) Чому іноді переміщення папки займає довше, ніж копіювання?

Тому що «переміщення» дерева директорій може стати штормом перейменувань і видалень, що викликає розриви lease і оновлення метаданих. Копія
може бути плавнішим потоковим навантаженням, якщо клієнти не конкурують за простір імен.

3) Якщо я вимкну надійні дескриптори, чи стануть переміщення нормальними?

Зазвичай ні. Якщо ваше «переміщення» насправді — copy+delete через межі шарів/датасетів, вимкнення durable не змінить цього.
Якщо ж проблема в розривах lease і утриманні дескрипторів, відключення durable може зменшити стан, але погіршить поведінку перепідключення.
Спочатку виправляйте архітектуру, потім налаштовуйте.

4) Чому переміщення між двома папками в одному шарі все одно поводиться як копія?

Два каталоги можуть знаходитись на різних датасетах через точки монтування всередині шляху шару. Шлях виглядає суцільним; файловая система — ні.
Підтвердіть через zfs list -o mountpoint і шлях path = вашої шари.

5) Який зв’язок між lease SMB і «зависаннями»?

Коли серверу потрібно, щоб клієнт скинув кеш або скинув незакінчені записи, він ламає lease. Якщо клієнт повільно відповідає (спить, завантажений CPU,
AV‑скан), сервер чекає. Ваше переміщення чекає. Це коректність, яка виконує свою роботу.

6) Чому Explorer показує «обчислення часу» нескінченно?

Explorer погано відчуває навантаження, доміновані метаданими й дрібними файлами, особливо по мережі. Він також погано оцінює операції, які в середині змінюють природу
(частково rename, частково fallback до copy).

7) Чи сповільнюють снапшоти SMB-переміщення?

Снапшоти зазвичай не сповільнюють саме перейменування. Вони впливають на видалення й звільнення місця. Якщо ви робите copy+delete між датасетами,
снапшоти на джерелі або призначенні можуть змінити ампліфікацію записів і результати по ємності.

8) Як довести керівництву, що «переміщення стало копіюванням»?

Покажіть стійку пропускну здатність записів пулу під час «переміщення» (Завдання 12). Потім покажіть межу датасету або відображення шарів (Завдання 1/3).
Перейменування не генерує великі секвенційні записи; копіювання — генерує.

9) Чи відрізняється це на TrueNAS або інших ZFS appliance?

Принципи ті самі. Агрегат може надати інші регулятори або значення за замовчуванням, але семантика SMB не змінюється: rename атомарний тільки в межах файлової системи/шару;
durable дескриптори й leases все одно вимагають підтримки стану й координації.

10) Що змінити спочатку: налаштування ZFS чи Samba?

Ні те, ні інше. Змініть розкладку насамперед: тримайте звичні переміщення в межах одного датасету/шару. Потім вимірюйте. Тільки після визначення вузького місця
налаштовуйте: латентність метаданих, конкуренцію блокувань або політику синхронності.

Наступні кроки, які варто виконати

Якщо ви хочете, щоб копіювання/переміщення припинили здаватися дивними, перестаньте вважати це таємницею й почніть підходити як до задачі класифікації:
rename чи copy? Коли ви знаєте відповідь, виправлення стає очевидним і зазвичай нудним.

1. Інвентаризуйте ваші шари й датасети і накресліть карту меж, які користувачі не повинні випадково перетинати в звичних робочих процесах.
2. Оберіть одну зону «швидких переміщень» (один датасет, один корінь шару) для команд, що часто реорганізують дані.
3. Інструментуйте розриви lease і блокування (тимчасово підвищуйте рівень логування під час інцидентів), щоб розрізняти «контенцію клієнтів» і «латентність сховища».
4. Заплануйте великі реорганізації та міграції поза піком і використовуйте керовані інструменти замість Explorer.
5. Вирівняйте політику снапшотів із реальністю: якщо бізнес очікує негайного повернення простору, не тримайте довгоживучих снапшотів на цьому датасеті.

Надійні дескриптори виконують роботу з забезпечення надійності, яку ви не хочете виконувати вручну. Дозвольте їм це робити. Просто не будуйте шар/датасет так, що
кожне «переміщення» перетворюється на копію, а потім дивуйтеся, коли фізика нагряне.