# Загрузка файлов на Samba-сервер с HDD идёт в два раза медленнее скачивания, а NFS быстрее: параметр strict sync

**URL:** <https://kryptos.forum/t/zagruzka-fajlov-na-samba-server-s-hdd-idyot-v-dva-raza-medlennee-skachivaniya-a-nfs-bystree-parametr-strict-sync/265>\
**Category:** Виртуальные машины и серверы\
**Tags:** виртуальные-машины\
**Created:** [30.Сентябрь.2026 10:32:35 UTC](https://kryptos.forum/t/zagruzka-fajlov-na-samba-server-s-hdd-idyot-v-dva-raza-medlennee-skachivaniya-a-nfs-bystree-parametr-strict-sync/265 "2026-09-30T10:32:35Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![team\_vm](https://kryptos.forum/letter_avatar_proxy/v4/letter/t/779978/32.png) [@team\_vm](https://kryptos.forum/u/team_vm)\
**Post date:** [30.Сентябрь.2026 10:32:35 UTC](https://kryptos.forum/t/zagruzka-fajlov-na-samba-server-s-hdd-idyot-v-dva-raza-medlennee-skachivaniya-a-nfs-bystree-parametr-strict-sync/265/1 "2026-09-30T10:32:35Z")

</div>

**Что было.** Файловый сервер на Debian 12 с общими папками Samba на жёстких дисках. Скачивание 112 МБ/с (гигабитная сеть), загрузка с клиентов Windows около 40 МБ/с. По NFS и SCP на тот же сервер 90 МБ/с; шары на SSD дают полную скорость в обе стороны. Процессор свободен, диск загружен на те же 40 МБ/с.

**Причина.** Начиная с Samba 4.x параметр `strict sync` по умолчанию `yes`: сервер честно выполняет `fsync` по каждому запросу клиента на сброс буферов, а клиенты Windows шлют такие запросы часто. На SSD это незаметно, на HDD каждый `fsync` это ожидание позиционирования головок. Автор добавил в `smb.conf` одну строку и получил ~90 МБ/с; прочие «оптимизации» (`socket options`, `aio`, размеры буферов) эффекта не дали. Подтверждено.

**Настройка.**

```auto
[global]
   strict sync = no

```

`testparm`, затем `smbcontrol all reload-config`. Компромисс: при внезапном отключении питания последние секунды записи могут не дойти до диска, хотя клиент считал их записанными. На сервере с резервным питанием и на виртуальной машине с надёжным хранилищем риск невелик; для критичных данных оставить `yes` и переносить шару на SSD.

**Что ещё влияет на скорость Samba, по убыванию.**

1. Носитель и файловая система назначения: HDD с мелкими файлами медленны при любом протоколе; `ext4` с `noatime`.
2. Версия протокола: `server min protocol = SMB3` (без SMB1) и на клиенте SMB3 с многоканальностью при нескольких адаптерах (`server multi channel support = yes`).
3. Подпись и шифрование: `server signing = mandatory` и `smb encrypt = required` добавляют нагрузку на процессор; на одном ядре виртуальной машины могут стать потолком.
4. Антивирус на клиенте Windows сканирует сетевые записи; на сервере сканер файлов (`vfs objects` с антивирусными модулями) удваивает время.
5. `aio read size`/`aio write size` по умолчанию включены и уже помогают; ручные `socket options` в современных ядрах чаще вредят.

**Как измерять.** Один большой файл (`dd if=/dev/urandom of=test bs=1M count=2048`) в обе стороны через шару и через `scp`: если `scp` быстрее Samba на записи, дело в настройках Samba, а не в сети или диске. `iostat -x 1` на сервере во время копирования: высокий `w_await` при низкой пропускной способности признак частых `fsync`.

Параметр описан в [документации Samba](https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#STRICTSYNC).