Ubuntu 24.04: CIFS болісно повільний — опції монтування, які зазвичай виправляють пропускну здатність (випадок №22)

November 15, 2025 • February 3, 2026 • Читання: 6 хв • Views: 7

Було корисно?

Ви змонтували Windows-шару на Ubuntu 24.04, запустили копіювання і тепер спостерігаєте 12 МБ/с на лінії 10 GbE, поки ваше терпіння вислизає крізь вуха. Тим часом CPU нудьгує, диски нудьгують, а черга інцидентів зовсім не нудьгує.

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

Кілька фактів, які справді важливі

Контекст не змусить пакети рухатися швидше, але він завадить вам крутити не ті ручки. Ось кілька коротких конкретних фактів і історичних деталей, що з’являються в реальних розслідуваннях:

SMB старший за ваші останні три «сучасні» стекi зберігання. Він веде свій початок із 1980-х; сучасний SMB3 — це та сама родина з шарами безпеки й оптимізаціями продуктивності, доданими з часом.
Linux CIFS — це не юзерспейсний FUSE-іграшка. Сучасний Linux-клієнт — модуль ядра (cifs.ko) з десятиліттями налаштувань, але він успадковує семантику SMB (балакучі метадані, блокування, ACL).
SMB1 мертвий з причин продуктивності та безпеки. SMB2/3 зменшили балакучість і покращили пайплайнинг, але ви все ще можете зробити SMB3 повільним через випадкове увімкнення затратних функцій.
Підписування та шифрування SMB не безкоштовні. Вони додають обробку CPU на пакет і можуть відключати деякі апаратні оптимізації NIC. Чудово для ворожих мереж. Жахливо для «чому це на 200 МБ/с повільніше, ніж учора?»
Затримка шкодить SMB більше, ніж очікують люди. SMB може пайплайни, але навантаження, насичені метаданими, все ще залежать від кругових поїздок. Підйом на 2 мс може розбити сканування каталогів і копіювання малих файлів.
Операції з каталогом — це інший вид спорту, ніж потокові читання. «Я можу читати великий файл на 900 МБ/с» і «мільйон дрібних файлів займає години» можуть бути обидва правдою.
Параметри монтування за замовчуванням — обережні. Linux за замовчуванням надає перевагу коректності та сумісності. Це нормально — поки ви не хочете продуктивності і знаєте своє середовище.
SMB Multichannel існує, але не творить магії сам по собі. Воно може використовувати кілька NIC/черг, але лише якщо сервер, клієнт і мережевий стек узгоджені (і ви не прив’язані до одного TCP-потоку випадково).
«Повільний CIFS» часто означає «повільний DNS/Kerberos». Затримки аутентифікації й таймаути імен можуть зробити монтування та перепідключення болючими, навіть якщо стійка пропускна здатність у порядку.

Одна цитата, що досі актуальна в операціях: Надія — це не стратегія. — генерал Гордон Р. Салліван.

Швидкий план діагностики (швидко знайдіть вузьке місце)

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

По-перше: підтвердьте, що означає «повільно»

Повільно для великих послідовних I/O? Підозрюйте підписування/шифрування, обмеження одного TCP-потоку, проблеми MTU, апаратні оффлоади NIC, або обмеження на сервері.
Повільно для малих файлів / метаданих? Підозрюйте затримку, політику кешування атрибутів, серверний антивірус/сканування, пошук за ACL, повідомлення про зміни, поведінку перерахування каталогів.
Повільно лише іноді? Підозрюйте DFS-реферали, поведінку перепідключення, роумінг Wi‑Fi, TCP-завантаження, фонове сканування, конкуренцію на сервері або файрвол, що проводить «корисну інспекцію».

По-друге: ізолюйте мережу vs зберігання vs накладні витрати протоколу

Мережевий базовий рівень: запустіть iperf3 до того самого сервера (або тієї самої підмережі). Якщо мережа не дає швидкість — CIFS теж не дасть.
Локальний базовий рівень сервера: якщо можете, перевірте пропускну здатність диска на сервері (або принаймні завантаження CPU під час SMB-передач). Якщо сервер завантажений криптоопераціями — ви знайшли злочинця.
Підтвердження протоколу: перевірте погоджений діалект SMB, підписування, шифрування і чи використовується multichannel.

По-третє: змінюйте одну річ, вимірюйте, зберігайте докази

Почніть з відключення затратних функцій безпеки тільки якщо політика безпеки дозволяє (підписування/шифрування). Якщо ні — плануйте потужність CPU і розгляньте AES‑NI, апаратні оффлоади NIC або швидші ядра.
Потім налаштовуйте кешування й поведінку атрибутів відповідно до навантаження (CI/CD-кеші, спільні таблиці, домашні директорії).
Нарешті, вирішуйте питання форми навантаження: паралелізм, пакування дрібних файлів, параметри robocopy/rsync, та виключення індексації/антивірусу на сервері.

Жарт №1: Налаштування продуктивності SMB схоже на дієту — зазвичай вирішення в тому, щоб «перестати перекушувати на виклики метаданих для кожного файлу».

Спочатку базова перевірка: доведіть, що це CIFS, а не мережа

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

Шлях: чи монтуєте ви правильну ціль (DFS може переслати вас кудись ще)?
Транспорт: чи ви на дротовому Ethernet, у правильному VLAN і з правильною MTU?
Сервер: чи сервер SMB здоровий, або тихо завантажений підписуванням/шифруванням/антивірусом?

Скарги на пропускну здатність SMB часто стають предметом суперечок між командами: мережа каже «це зберігання», зберігання каже «це мережа», безпека каже «працює як задумано», а команда застосунку вже пише Slack-потік під назвою «Linux повільний». Ваше завдання — перетворити відчуття на метрики.

Опції монтування, що зазвичай виправляють пропускну здатність

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

Почніть з розумної, сучасної бази

Використовуйте SMB3, якщо немає дуже конкретної спадщинної причини не робити цього. На Ubuntu 24.04 ваше ядро та cifs-utils досить сучасні для цього.

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,uid=1000,gid=1000,dir_mode=0770,file_mode=0660,soft,nounix,serverino

Це ще не «швидкий» монтування. Це «передбачуване» монтування:

vers=3.1.1: фиксирує діалект; уникає дивних даунгрейдів.
nounix: запобігає припущенням про POSIX-розширення, які можуть ускладнити сумісність.
serverino: стабільні номери інодів від сервера; допомагає деяким інструментам і зменшує сюрпризи.
soft: повертає помилки швидше при проблемах сервера (рішення приймайте обережно; див. розділ про помилки).

Перемоги по пропускній здатності: зменшіть накладні витрати на операцію I/O (якщо дозволено)

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

Опція: відключити підписування (тільки якщо політика дозволяє)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,seal=no,sign=no,cache=none,actimeo=1

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

Опція: зберегти безпеку, але переконатися, що CPU не вузьке місце

Якщо ви мусите мати підписування/шифрування, ставтеся до цього як до TLS: вам потрібен запас CPU і бажано апаратне прискорення (AES‑NI). Якщо віртуальній машині виділені слабкі vCPU або є «шумні сусіди», пропускна здатність виглядатиме як проблема протоколу.

Навантаження, насичене метаданими: опції кешування, які важливі

За замовчуванням семантика кешування обережна. Це добре для коректності з кількома клієнтами. Воно також може зробити кожну збірку або розпаковування відчутними як рух крізь мед.

`cache=strict` проти `cache=none`

cache=none: менше сюрпризів; часто повільніше для повторних читань і метаданих.
cache=strict: може прискорити читання, залишаючись відносно коректним, але все одно обмежується викликами метаданих.

`actimeo` (таймаут кешу атрибутів)

Для навантажень, що часто роблять stat() файлів (системи збірки, сканери залежностей), збільшення кешування атрибутів може бути трансформаційним.

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/engineering /mnt/eng \
  -o vers=3.1.1,username=alice,domain=CORP,cache=strict,actimeo=30

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

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

SMB має виконати кілька операцій на файл: create/open, query info, read/write, close, update metadata. Помножте на 500 000 файлів — і ви отримали бенчмарк затримки.

Опції монтування допомагають трохи (кешування, менше кругових поїздок), але великі перемоги часто: знизити кількість файлів (упакувати в tar), обережно підвищити паралелізм або перемістити навантаження в об’єктне сховище / локальний SSD scratch, а потім синхронізувати.

Продуктивність для «великих файлів»: слідкуйте за пасткою одного потоку

Багато операцій «копіювання великого файлу» на практиці — це один TCP-потік. На швидких каналах з помірною затримкою один потік може не завантажувати канал, якщо параметри масштабування вікна, управління заторами та розміри буферів не оптимальні. SMB Multichannel може допомогти, але лише тоді, коли він погоджений і підтримується.

Жарт №2: Найшвидша SMB-передача — та, яку ваша команда безпеки не змусила зашифрувати — на жаль, вони зазвичай це помічають.

Чому форма навантаження має значення (великі проти малих файлів)

У продакшені «CIFS повільний» зазвичай означає одне з цих:

Великі послідовні читання/записи повільні: ви платите податок за шифрування/підписування, застрягли на одній дорозі або сховище сервера насичене.
Малі файли повільні: домінують затримки та операції з метаданими; кешування і серверні сканування важливіші за сире throughput.
Перерахування каталогу повільне: ви перераховуєте величезні каталоги, потрапляєте на витрати ACL, або клієнт робить зайві виклики stat.
Монтування/підключення повільне: DNS, Kerberos, розбіжність часу або повторні спроби встановлення сесії SMB.

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

12+ практичних завдань: команди, виводи, рішення

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

Завдання 1: Підтвердьте версії ядра та cifs-utils (ви відлагоджуєте змінний об’єкт)

cr0x@server:~$ uname -r
6.8.0-41-generic
cr0x@server:~$ dpkg -l | egrep 'cifs-utils|linux-modules-extra' | head
ii  cifs-utils                    2:7.0-2ubuntu0.1   amd64  Common Internet File System utilities
ii  linux-modules-extra-6.8.0-41-generic  6.8.0-41.41 amd64  Linux kernel extra modules for version 6.8.0

Рішення: Якщо linux-modules-extra відсутній, ви можете втратити опціональні модулі й інструменти. Якщо ядро застаріле (не у вашому випадку на 24.04) — оновіть перед налаштуванням.

Завдання 2: Перевірте деталі монтування та погоджені можливості SMB

cr0x@server:~$ mount | grep 'type cifs'
//fs01.corp.example/engineering on /mnt/eng type cifs (rw,relatime,vers=3.1.1,cache=strict,username=alice,uid=1000,gid=1000,soft,serverino,actimeo=1)

Рішення: Підтвердьте, що ви фактично використовуєте SMB3.1.1, і подивіться на кешування/actimeo. Якщо очікуваний прапорець налаштування відсутній — ви не тестуєте те, що думаєте, що тестуєте.

Завдання 3: Витягніть налаштування SMB-сесії з ядра (діалект, підписування, шифрування)

cr0x@server:~$ sudo cat /proc/fs/cifs/DebugData | sed -n '1,120p'
CIFS Version 2.48
Features: DFS,FSCACHE,STAT,SMB_DIRECT,INODE64,ACL,SMB2,SMB3,OPLOCKS,SECURITY
Active VFS Requests: 0
Servers:
1) Name: fs01.corp.example
   TCP status: connected
   Dialect: 3.1.1
   Security: signing required
   Encryption: yes
   Session User: CORP\alice
Shares:
1) \\fs01.corp.example\engineering
   Mounts: 1
   UNC: \\fs01.corp.example\engineering
   Options: rw,relatime,soft,serverino,actimeo=1,cache=strict

Рішення: Якщо підписування вимагається і шифрування увімкнено — очікуйте накладні витрати CPU. Якщо пропускна здатність низька і CPU високо завантажений на будь-якій стороні — швидше за все ви знайшли обмежувача.

Завдання 4: Мережевий базовий рівень з iperf3

cr0x@server:~$ iperf3 -c fs01.corp.example -P 4 -t 10
Connecting to host fs01.corp.example, port 5201
[SUM]   0.00-10.00  sec  9.45 GBytes  8.12 Gbits/sec  sender
[SUM]   0.00-10.00  sec  9.41 GBytes  8.08 Gbits/sec  receiver

Рішення: Мережа може забезпечити ~8 Gbit/s, отже 100–200 Mbit/s при копіюванні SMB — це не «мережа». Тепер ви можете припинити сперечатися з мережею і почати сперечатися з доказами.

Завдання 5: Підтвердіть стабільність шляху (DNS, зворотні запити та реферали)

cr0x@server:~$ getent hosts fs01.corp.example
10.20.30.40   fs01.corp.example
cr0x@server:~$ smbclient -L fs01.corp.example -U 'CORP\alice' -m SMB3 | head
	Sharename       Type      Comment
	---------       ----      -------
	engineering     Disk
	IPC$            IPC       IPC Service (SMB Server)
SMB1 disabled -- no workgroup available

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

Завдання 6: Виміряйте реальну пропускну здатність копіювання одного великого файлу

cr0x@server:~$ dd if=/dev/zero of=/mnt/eng/test-10g.bin bs=16M count=640 oflag=direct status=progress
10737418240 bytes (11 GB, 10 GiB) copied, 33 s, 325 MB/s
640+0 records in
640+0 records out
10737418240 bytes copied, 33.0589 s, 325 MB/s

Рішення: Якщо пропускна здатність для великих файлів низька — фокусуйтеся на підписуванні/шифруванні, multichannel, апаратних оффлоадах NIC, CPU сервера та бекінгу сховища. Якщо великі файли в порядку, а дрібні — жах, переходьте до налаштувань метаданих/кешування та зміни навантаження.

Завдання 7: Виміряйте біль від метаданих (цикл create/stat/unlink)

cr0x@server:~$ time bash -c 'd=/mnt/eng/meta-test; mkdir -p "$d"; for i in $(seq 1 20000); do echo x > "$d/f$i"; done; sync'
real	2m3.412s
user	0m8.941s
sys	0m47.228s

Рішення: Якщо це хвилини для 20k дрібних файлів — ви обмежені затримкою/метаданими. Розгляньте actimeo, виключення AV на сервері, пакування файлів або переміщення робочого процесу поза SMB.

Завдання 8: Перевірте насичення CPU на клієнті під час передач

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.8.0-41-generic (cr0x) 	12/30/2025 	_x86_64_	(8 CPU)

12:10:01 PM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
12:10:02 PM  all  12.10   0.00  22.55    0.20  0.00   1.10    0.00  64.05
12:10:02 PM    3  70.00   0.00  25.00    0.00  0.00   2.00    0.00   3.00

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

Завдання 9: Перевірте швидкість NIC/дуплекс і помилки (бо реальність сувора)

cr0x@server:~$ sudo ethtool eno1 | egrep 'Speed|Duplex|Auto-negotiation|Link detected'
	Speed: 10000Mb/s
	Duplex: Full
	Auto-negotiation: on
	Link detected: yes
cr0x@server:~$ ip -s link show eno1 | sed -n '1,12p'
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    RX:  bytes packets errors dropped  missed   mcast
  9812134321  8123123      0      12       0  112233
    TX:  bytes packets errors dropped carrier collsns
  8741123988  7012231      0       0       0       0

Рішення: Помилки/скидання означають ретрансмісію, що SMB інтерпретує як «чому все липне?». Виправте фізичні/мережеві проблеми перед налаштуванням протоколу.

Завдання 10: Перевірте MTU вкінці в кінець (PMTUD проблеми виглядають як повільний SMB)

cr0x@server:~$ ping -c 3 -M do -s 1472 fs01.corp.example
PING fs01.corp.example (10.20.30.40) 1472(1500) bytes of data.
1480 bytes from 10.20.30.40: icmp_seq=1 ttl=62 time=0.412 ms
1480 bytes from 10.20.30.40: icmp_seq=2 ttl=62 time=0.396 ms
1480 bytes from 10.20.30.40: icmp_seq=3 ttl=62 time=0.401 ms

--- fs01.corp.example ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms
rtt min/avg/max/mdev = 0.396/0.403/0.412/0.007 ms

Рішення: Якщо ви бачите «Frag needed» або таймаути — ситуація з jumbo/PMTUD зламана. Виправте це; SMB перестане зависати.

Завдання 11: Перевірте наявність SMB multichannel і RDMA (якщо ви очікували)

cr0x@server:~$ sudo grep -iE 'SMB_DIRECT|RDMA|Multi' /proc/fs/cifs/DebugData
Features: DFS,FSCACHE,STAT,SMB_DIRECT,INODE64,ACL,SMB2,SMB3,OPLOCKS,SECURITY

Рішення: Побачити SMB_DIRECT у списку можливостей не означає, що ви його використовуєте. Якщо вам потрібен RDMA/Direct — перевірте підтримку на сервері та налаштування NIC/драйвера. Інакше вважайте, що використовується класичний TCP.

Завдання 12: Визначте «податок безпеки», переключивши політику тестової шару (у лабораторії)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/lab-nosign /mnt/lab \
  -o vers=3.1.1,username=alice,domain=CORP,sign=no,seal=no,cache=strict,actimeo=30
cr0x@server:~$ dd if=/dev/zero of=/mnt/lab/test-5g.bin bs=16M count=320 oflag=direct status=progress
5368709120 bytes (5.4 GB, 5.0 GiB) copied, 9 s, 594 MB/s

Рішення: Якщо продуктивність подвоюється в контрольованому тесті при вимкненому підписуванні/шифруванні — ваша «таємниця» це вартість політики. Ескалюйте з числами, а не скаргами: «шифрування знижує пропускну здатність приблизно на 45% на цьому класі клієнтів».

Завдання 13: Підтвердьте, що сервер не обмежує шаром SMB (приклад Windows з Linux)

cr0x@server:~$ smbclient //fs01.corp.example/engineering -U 'CORP\alice' -m SMB3 -c 'get test-10g.bin /dev/null; quit'
getting file \test-10g.bin of size 10737418240 as /dev/null (312.4 MB/s) (average 312.4 MB/s)

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

Завдання 14: Перегляньте dmesg на предмет попереджень CIFS (тихі повторні спроби повільні)

cr0x@server:~$ sudo dmesg -T | egrep -i 'cifs|smb3' | tail -n 12
[Mon Dec 30 12:02:11 2025] CIFS: VFS: \\fs01.corp.example has not responded in 180 seconds. Reconnecting...
[Mon Dec 30 12:02:12 2025] CIFS: VFS: cifs_reconnect: reconnect to server fs01.corp.example

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

Завдання 15: Підтвердьте синхронізацію часу (проблеми Kerberos/аутентифікації можуть уповільнити монтування/перепідключення)

cr0x@server:~$ timedatectl
               Local time: Mon 2025-12-30 12:12:44 UTC
           Universal time: Mon 2025-12-30 12:12:44 UTC
                 RTC time: Mon 2025-12-30 12:12:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

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

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

Міні-історія №1: Інцидент через неправильне припущення

Компанія: середній SaaS, Windows-файлові сервіси для спільних інженерних артефактів. Команда мігрувала ранери збірки з Ubuntu 22.04 на 24.04. Першого понеділка після розгортання час збірки різко зріс. Люди звинувачували «нове ядро Ubuntu» і почали зафіксовувати старі образи.

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

На папері це було «працює як задумано». На практиці — інцидент у продакшені: пропускна здатність збірок впала, пайплайни накопичилися, і on-call довелося пояснювати, чому «покращення безпеки» мали незаплановану ціну, яку ніхто не тестував.

Виправлення не було магічною опцією монтування. Це було рішення: або зберегти шифрування і надати більше CPU на SMB-серверах (та впевнитися в AES‑NI для класу VM), або сегментувати мережу і дозволити незашифрований SMB на внутрішньому шляху з компенсуючими заходами. Вони обрали перше для чутливих репозиторіїв і виділили незашифрований шар для некритичних кешів.

Урок: базові показники продуктивності повинні включати безпекову позицію. Якщо ви цього не вимірюєте, ви «відкриєте» це о 2-й ночі.

Міні-історія №2: Оптимізація, що відкотилася проти всіх

Фінансова організація мала аналітичний кластер на Ubuntu, що монтував CIFS-шару для нічних CSV. Хтось помітив, що монтування використовує cache=none і actimeo=1, та вирішив «прискорити» це, піднявши actimeo=600 і ввівши строгі кеші повсюди.

Пропускна здатність покращилася. Перерахування каталогів прискорилося. Усі святкували, недовго.

Потім почалися сповіщення про якість даних. Підрядна задача читала файли, які були замінені на шарі, але клієнт тримав кешовані атрибути достатньо довго, щоб пайплайн подумав «файл не змінено» і пропустив інгест. Зміна кешування була правильна з точки зору продуктивності і невідповідна з точки зору семантики. Бізнес не переймався SMB-настройками; їм були важливі свіжі звіти.

Вони відкотили зміни і замінили їх на нудний дизайн: система-джерело записує у staging-директорію, потім робить атомарний перейменунок у «ready»-директорію. Споживачі читають лише з «ready» і використовують контрольні суми. З таким робочим процесом actimeo=30 стало безпечним і ефективним.

Урок: не налаштовуйте кешування, поки не зрозумієте модель коректності. SMB — не ваша база даних. Ваш пайплайн все ще потребує правил.

Міні-історія №3: Нудна, але правильна практика, що врятувала день

Велике підприємство мало кілька флітів Linux, що монтували Windows-шари для профілів користувачів і конфігурацій застосунків. Щокварталу хтось скаржився: «CIFS знову повільний». Замість випадкових змін, команда SRE мала одну нудну звичку: відтворюваний бенчмарк і одна сторінка «відомо добре» профілів монтування.

Вони підтримували два профілі: Інтерактивний (домашні директорії, коректність понад усе) і Масовий (переважно читання, пріоритет пропускної здатності). Обидва були закодовані в конфіг-менеджменті з невеликим канарі, що запускав smbclient і тест dd на ядрі щодня. Результати графіли поруч із CPU сервера, скиданнями мережі й помилками аутентифікації.

Коли оновлення прошивки сховища спричинило періодичні втрати пакетів на одному верхньоштабному комутаторі, графіки SMB впали до того, як користувачі почали скаржитися. Канар також показав повторні підключення в dmesg. Мережа спочатку знизала плечима, бо «лінки вгору». Дані були надто конкретні: помилки на одному порту NIC, на одному стояку, скорельовані з повторними підключеннями SMB і обвалом пропускної здатності.

Вони виправили проблему фізичного шару і відновили продуктивність, не торкнувшись жодної опції монтування. Та нудна практика не була героїкою. Це була інструментація і задокументований базовий стан.

Урок: найшвидше налаштування CIFS — довести, що вам не потрібно налаштовувати CIFS.

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

1) Симптом: Великі файли обмежені 30–80 МБ/с на 10 GbE

Корінна причина: Потрібне шифрування/підписування SMB; клієнт або сервер завантажений CPU; обмеження одного TCP-потоку.

Виправлення: Перевірте підписування/шифрування через /proc/fs/cifs/DebugData. Якщо політика дозволяє — протестуйте seal=no,sign=no на лабораторній шарі. Інакше додайте CPU, переконайтесь у наявності AES‑NI, розгляньте SMB multichannel і підтвердіть, що апаратні оффлоади NIC не відключені політикою.

2) Симптом: Мільйони дрібних файлів займають вічність, а великі файли в порядку

Корінна причина: Кругові виклики метаданих і затримки; надто строгий кеш атрибутів; серверний антивірус сканує кожне open/close.

Виправлення: Обережно збільшіть actimeo (наприклад 10–30) для переважно читаних навантажень; пакуйте дрібні файли в архіви; додавайте паралелізм; координуйте виключення AV для певних шляхів.

3) Симптом: Перерахування каталогу болісно повільне

Корінна причина: Величезні каталоги; вартість оцінки ACL; клієнт робить зайві stat-виклики; розкидування DFS-рефералів.

Виправлення: Уникайте гігантських плоских каталогів; розділяйте за префіксом/датою/проектом. Підтвердіть стабільність цілі і відсутність сюрпризів DFS. Використовуйте кешування, відповідне вашим потребам консистентності.

4) Симптом: Монтування зависає на 30–60 секунд, потім працює

Корінна причина: DNS-таймаути, затримки зворотних запитів, повторні спроби Kerberos, розбіжність часу, затримки інспекції файрволом.

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

5) Симптом: Випадкові «сервер не відповідає» і перепідключення під навантаженням

Корінна причина: Втрати пакетів, проблеми MTU/PMTUD, ненадійний NIC/драйвер або перевантажений сервер, що потрапляє на таймаути.

Виправлення: Перевірте помилки/скидання інтерфейсу; підтвердіть MTU за допомогою ping -M do; шукайте повторні підключення CIFS у dmesg; виправте стабільність транспорту перед налаштуванням.

6) Симптом: Після «оптимізації продуктивності» додатки бачать застарілі дані

Корінна причина: Агресивне кешування атрибутів (actimeo) використано на шарі, чутливому до коректності.

Виправлення: Зменшіть actimeo (1–5) або використовуйте безпечний профіль; переробіть робочий процес з атомарними перейменуваннями і ready/staging директоріями.

7) Симптом: Linux-клієнти повільніші за Windows для тієї ж шари

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

Виправлення: Порівняйте погоджені налаштування на обох сторонах. Не порівнюйте Windows-клієнт у тій же VLAN з Linux-VM через файрвол і не називайте це науковим експериментом.

8) Симптом: Пропускна здатність падає лише по Wi‑Fi або VPN

Корінна причина: Затримка і втрати; MTU VPN; один TCP-потік; інспекція пакетів.

Виправлення: Використовуйте split tunneling, якщо дозволено; виправте MTU; застосуйте паралельні передачі; розгляньте переміщення масових операцій поза SMB у віддалих сценаріях.

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

Покроково: від скарги до виправлення без гадання

Класифікуйте повільність: великий файл vs дрібні файли vs перерахування каталогів vs час монтування.
Доведіть мережеву здатність за допомогою iperf3 (паралельні потоки).
Підтвердіть погоджені можливості SMB через /proc/fs/cifs/DebugData: діалект, підписування, шифрування.
Виміряйте контрольоване перенесення великого файлу (direct I/O), щоб уникнути ілюзій сторінкового кешу.
Виміряйте контрольований тест метаданих (цикл create/stat/unlink).
Перевірте стабільність: помилки NIC, MTU, логи повторних підключень CIFS.
Якщо підозра на «податок безпеки»: протестуйте в лабораторному шарі з вимкненим підписуванням/шифруванням; кількісно оцініть різницю.
Виберіть профіль монтування:
- Коректність перш за все: cache=none або обережний actimeo.
- Переважно читання / масово: cache=strict,actimeo=30 (або вище з гарантіями робочого процесу).
Впорядкуйте форму навантаження: запаковуйте дрібні файли, паралелізуйте, робіть локальний стейдж, уникайте гігантських каталогів.
Закодуйте: покладіть опції монтування в /etc/fstab (або systemd mount units) з коментарями і відповідальною особою.
Запобігайте регресіям: тримайте маленький бенчмарк/канар та сповіщення про відхилення.

Два профілі монтування, з якими реально працювати

Профіль A: Інтерактивний / коректність перш за все (домашні директорії, спільні редагування)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/homes /home \
  -o vers=3.1.1,sec=krb5,cache=none,actimeo=1,soft,serverino,uid=1000,gid=1000

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

Профіль B: Масовий, переважно читання (артефактний кеш, датасети, медіа)

cr0x@server:~$ sudo mount -t cifs //fs01.corp.example/artifacts /mnt/artifacts \
  -o vers=3.1.1,username=buildbot,domain=CORP,cache=strict,actimeo=30,serverino,uid=1000,gid=1000

Використовуйте коли: переважно читання, небагато записувачів, ви можете терпіти невелику застарілість атрибутів.

Питання та відповіді (FAQ)

1) Чому CIFS став повільнішим на Ubuntu 24.04 у порівнянні з 22.04?

Зазвичай воно не «стало повільнішим» саме по собі. Змінюються погоджені можливості SMB (діалект, підписування, шифрування), поведінка ядра або ваше середовище (політика безпеки, DNS, мережевий шлях). Порівняйте через /proc/fs/cifs/DebugData.

2) Яка опція монтування дає найбільший приріст пропускної здатності?

Якщо ви обмежені по CPU через функції безпеки, найбільший «приріст» дає відключення підписування/шифрування — тільки якщо політика дозволяє. Якщо не можна, наступні великі виграші — достатній CPU і відповідне кешування (cache=strict, розумний actimeo) для переважно читаних навантажень.

3) Чи завжди ставити `actimeo=30`?

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

4) Чи має сенс налаштовувати `rsize`/`wsize`?

Менше, ніж раніше, бо SMB2/3 і клієнт ядра динамічно управляють розмірами. Це все ще може мати значення в крайніх випадках (аплайенси, дивні середовища посередників), але це не перший важіль на Ubuntu 24.04.

5) Чому перерахування каталогу повільне, хоча пропускна здатність у порядку?

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

6) Чи безпечно використовувати `soft`?

Залежить від сценарію. soft може викликати помилки I/O замість того, щоб чекати вічно, що може бути придатним для пакетних завдань. Для баз даних несподівані помилки I/O можуть бути гірші за очікування. Обирайте свідомо, а не сліпо.

7) Використовувати `sec=krb5` чи username/password?

Kerberos (sec=krb5) зазвичай чистіше для корпоративних середовищ і уникає розповсюдження паролів, але більш чутливий до DNS і синхронізації часу. Якщо монтування повільні або нестабільні — перевірте NTP і квитки Kerberos.

8) Чи може SMB Multichannel виправити мої проблеми зі швидкістю?

Може, особливо на швидких лініях, де один TCP-потік не завантажує канал. Але воно потребує підтримки на сервері й правильної конфігурації мережі/NIC. Не припускайте, що воно ввімкнено; перевірте і протестуйте.

9) Чому `smbclient` здається швидшим, ніж змонтована файлову система?

smbclient — інший клієнтський шлях і інший патерн роботи. Якщо він швидкий, а змонтована ФС повільна — дивіться опції монтування, семантику кешування і патерни застосунку (багато stat/open). Якщо обидва повільні — дивіться на сервер/мережу/політику.

10) Який найшвидший спосіб перемістити мільйон дрібних файлів?

Не робіть цього. Упакуйте їх (tar/zstd), перемістіть один великий бінар, потім розпакуйте локально. Якщо потрібно зберегти як окремі файли — використовуйте паралелізм і прийміть, що метадані домінуватимуть. SMB — не високопродуктивне об’єктне сховище.

Висновок: що робити далі

Коли CIFS болісно повільний на Ubuntu 24.04, виправлення рідко полягає в «додаванні випадкових прапорців». Робіть дисципліновано:

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

Якщо хочете одну практичну наступну дію: збережіть /proc/fs/cifs/DebugData, результат iperf3 і тест великого файлу dd. З цими трьома артефактами ви зможете вести дорослу розмову з мережею, сховищем і безпекою — без гадань.