Я испытываю постоянные проблемы с задержкой записи при копировании больших файлов с клиентской Windows-машины на Samba-шару, работающую в контейнере LXC на моём сервере Proxmox VE. Хранилище для LXC — это NVMe SSD во внешнем корпусе USB 3.0.
**Описание проблемы:** Копирование больших файлов (например, видеофайлов >1 ГБ) на Samba-шару начинается с хорошей скоростью (иногда >100 МБ/с, вероятно, за счёт кэширования), но затем быстро ухудшается и в конечном итоге полностью останавливается, при этом скорость передачи данных падает до 0 МБ/с. Во время остановки iostat на хосте Proxmox VE показывает, что USB-диск (/dev/sda) загружен почти на 100% (%util) с очень высоким временем ожидания ввода-вывода (%iowait), но фактическая пропускная способность записи (wkB/s или wMB/s) падает до нуля или почти до нуля. Копирование файлов с сервера (Samba-шара) на клиентскую Windows-машину происходит быстро и работает нормально. Небольшие файлы при копировании на сервер, как правило, работают без проблем. Этот же NVMe-диск и корпус USB ранее работали без таких проблем с задержкой, когда были подключены непосредственно к моей Windows-машине.
**Системные спецификации:**
* Proxmox VE Version: 8.4.0 (Kernel: 6.8.12-10-pve)
* Вывод pveversion -v:
* proxmox-ve: 8.4.0 (running kernel: 6.8.12-10-pve)
* pve-manager: 8.4.1 (running version: 8.4.1/2a5fa54a8503f96d)
* (включите остальную часть вывода pveversion -v)
* zfsutils-linux: 2.2.7-pve2
* NVMe Drive: WD Blue SN580 1TB
* USB Enclosure: Kinsound M.2 NVMe SSD Enclosure (определяется dmesg как использующий чипсет JMicron с idVendor=152d, idProduct=0583)
* Proxmox Host Motherboard: BIOSTAR Group TB360-BTC PRO 2.0 (BIOS 5.13 06/08/2021)
* Конфигурация ZFS Pool ("tank"): Одноустрочный пул, использующий раздел /dev/sda4 с USB NVMe.
* Вывод zpool status tank:
* pool: tank
* state: ONLINE
* config:
* NAME STATE READ WRITE CKSUM
* tank ONLINE 0 0 0
* usb-JMicron\_Tech\_DD56419883890-0:0-part4 ONLINE 0 0 0
* # Или sda4, если это то, что показывает в настоящее время
* errors: No known data errors
* LXC Container ("100 (media)"): [Укажите ОС, если известно, например, Ubuntu 22.04]. Работает Samba-сервер.
* Релевантная точка монтирования для данных LXC: mp0: tank:subvol-100-disk-1,mp=/data,size=300G
* Клиентская ОС: Windows 10/11 [Укажите]
**Предпринятые шаги по устранению неполадок и основные выводы:**
* **Первоначальное наблюдение:** lsblk -D /dev/sda изначально показывало DISC-MAX: 0B, указывая на отсутствие поддержки TRIM на уровне ОС для USB-корпуса. zpool trim tank завершился ошибкой с сообщением "no devices in pool support trim operations".
* **Исследование проблем TRIM с JMicron JMS583 в Linux:** Нашёл обсуждения на форумах, предполагающие, что правило udev может помочь для устройств, сообщающих lbpme=0, но LBPU=1.
* **Проверка возможностей SCSI:** sg\_readcap -l /dev/sda показало: Logical block provisioning: lbpme=0, lbprz=0. sg\_vpd -p lbpv /dev/sda показало: Поддерживается команда Unmap (LBPU): 1.
* **Применение правила udev:** Создано /etc/udev/rules.d/90-usb-nvme-jms583-trim.rules с:
* ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0583", SUBSYSTEM=="scsi\_disk", ATTR{provisioning\_mode}="unmap", ATTR{manage\_start\_stop}="1"
* **Результат применения правила udev:** После перезагрузки правил и повторного подключения устройства lsblk -D /dev/sda теперь показывает DISC-MAX: 4G для /dev/sda и /dev/sda4.
* **Тест ZFS TRIM:** zpool trim tank затем успешно завершился без ошибок.
* **ZFS autotrim:** zpool get autotrim tank показало, что он отключён по умолчанию. Я включил его командой zpool set autotrim=on tank.
* **Текущая проблема - ошибки UNMAP:** Несмотря на то, что DISC-MAX показывает 4G и ручной zpool trim работал один раз изначально, копирование файлов по-прежнему останавливается. Кроме того, dmesg теперь показывает критические ошибки во время операций TRIM/DISCARD при активном autotrim или во время записи:
* \[ 85.821360] sd 6:0:0:0: \[sda] tag#0 FAILED Result: hostbyte=DID\_OK driverbyte=DRIVER\_OK cmd\_age=0s
* \[ 85.821365] sd 6:0:0:0: \[sda] tag#0 Sense Key : Illegal Request \[current]
* \[ 85.821366] sd 6:0:0:0: \[sda] tag#0 Add. Sense: Logical block address out of range
* \[ 85.821368] sd 6:0:0:0: \[sda] tag#0 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
* \[ 85.821369] critical target error, dev sda, sector 1116008816 op 0x3:(DISCARD) flags 0x0 phys\_seg 1 prio class 0
* \[ 85.821371] zio pool=tank vdev=/dev/disk/by-id/usb-JMicron\_Tech\_DD56419883890-0:0-part4 error=121 type=6 offset=464021282816 size=40960 flags=524480 (Эти ошибки повторяются)
* **Текущее состояние:** Из-за этих ошибок UNMAP я временно отключил autotrim (zpool set autotrim=off tank) и удалил правило udev (/etc/udev/rules.d/90-usb-nvme-jms583-trim.rules, перезагрузил правила, повторно подключил устройство). Проблема со сбоями по-прежнему сохраняется.
* **Свойство ZFS sync для набора данных LXC:** zfs get sync tank/subvol-100-disk-1 показывает standard.
**Вопросы:**
* Учитывая ошибки "Logical block address out of range" во время операций DISCARD даже при DISC-MAX, не подтверждает ли это неисправленную реализацию TRIM/UNMAP во встроенном ПО моего корпуса Kinsound (JMicron JMS583) при использовании с Linux?
* Находил ли кто-нибудь надежное решение или обходной путь для этих конкретных ошибок UNMAP с устройствами 152d:0583 в последних Proxmox/Linux-ядрах, помимо стандартной правки provisioning\_mode udev?
* Могут ли сами неудачные команды UNMAP (когда была предпринята попытка TRIM) вызывать или усугублять сбои записи?
* Есть ли какие-либо другие настройки ZFS или параметры ядра, которые следует изучить для одноустрочного пула ZFS в Proxmox?
* Нужно ли искать другой корпус NVMe, например, с другим контроллером (ASMedia или другой)?
Буду благодарен за любые идеи или предложения. Спасибо!
**Описание проблемы:** Копирование больших файлов (например, видеофайлов >1 ГБ) на Samba-шару начинается с хорошей скоростью (иногда >100 МБ/с, вероятно, за счёт кэширования), но затем быстро ухудшается и в конечном итоге полностью останавливается, при этом скорость передачи данных падает до 0 МБ/с. Во время остановки iostat на хосте Proxmox VE показывает, что USB-диск (/dev/sda) загружен почти на 100% (%util) с очень высоким временем ожидания ввода-вывода (%iowait), но фактическая пропускная способность записи (wkB/s или wMB/s) падает до нуля или почти до нуля. Копирование файлов с сервера (Samba-шара) на клиентскую Windows-машину происходит быстро и работает нормально. Небольшие файлы при копировании на сервер, как правило, работают без проблем. Этот же NVMe-диск и корпус USB ранее работали без таких проблем с задержкой, когда были подключены непосредственно к моей Windows-машине.
**Системные спецификации:**
* Proxmox VE Version: 8.4.0 (Kernel: 6.8.12-10-pve)
* Вывод pveversion -v:
* proxmox-ve: 8.4.0 (running kernel: 6.8.12-10-pve)
* pve-manager: 8.4.1 (running version: 8.4.1/2a5fa54a8503f96d)
* (включите остальную часть вывода pveversion -v)
* zfsutils-linux: 2.2.7-pve2
* NVMe Drive: WD Blue SN580 1TB
* USB Enclosure: Kinsound M.2 NVMe SSD Enclosure (определяется dmesg как использующий чипсет JMicron с idVendor=152d, idProduct=0583)
* Proxmox Host Motherboard: BIOSTAR Group TB360-BTC PRO 2.0 (BIOS 5.13 06/08/2021)
* Конфигурация ZFS Pool ("tank"): Одноустрочный пул, использующий раздел /dev/sda4 с USB NVMe.
* Вывод zpool status tank:
* pool: tank
* state: ONLINE
* config:
* NAME STATE READ WRITE CKSUM
* tank ONLINE 0 0 0
* usb-JMicron\_Tech\_DD56419883890-0:0-part4 ONLINE 0 0 0
* # Или sda4, если это то, что показывает в настоящее время
* errors: No known data errors
* LXC Container ("100 (media)"): [Укажите ОС, если известно, например, Ubuntu 22.04]. Работает Samba-сервер.
* Релевантная точка монтирования для данных LXC: mp0: tank:subvol-100-disk-1,mp=/data,size=300G
* Клиентская ОС: Windows 10/11 [Укажите]
**Предпринятые шаги по устранению неполадок и основные выводы:**
* **Первоначальное наблюдение:** lsblk -D /dev/sda изначально показывало DISC-MAX: 0B, указывая на отсутствие поддержки TRIM на уровне ОС для USB-корпуса. zpool trim tank завершился ошибкой с сообщением "no devices in pool support trim operations".
* **Исследование проблем TRIM с JMicron JMS583 в Linux:** Нашёл обсуждения на форумах, предполагающие, что правило udev может помочь для устройств, сообщающих lbpme=0, но LBPU=1.
* **Проверка возможностей SCSI:** sg\_readcap -l /dev/sda показало: Logical block provisioning: lbpme=0, lbprz=0. sg\_vpd -p lbpv /dev/sda показало: Поддерживается команда Unmap (LBPU): 1.
* **Применение правила udev:** Создано /etc/udev/rules.d/90-usb-nvme-jms583-trim.rules с:
* ACTION=="add|change", ATTRS{idVendor}=="152d", ATTRS{idProduct}=="0583", SUBSYSTEM=="scsi\_disk", ATTR{provisioning\_mode}="unmap", ATTR{manage\_start\_stop}="1"
* **Результат применения правила udev:** После перезагрузки правил и повторного подключения устройства lsblk -D /dev/sda теперь показывает DISC-MAX: 4G для /dev/sda и /dev/sda4.
* **Тест ZFS TRIM:** zpool trim tank затем успешно завершился без ошибок.
* **ZFS autotrim:** zpool get autotrim tank показало, что он отключён по умолчанию. Я включил его командой zpool set autotrim=on tank.
* **Текущая проблема - ошибки UNMAP:** Несмотря на то, что DISC-MAX показывает 4G и ручной zpool trim работал один раз изначально, копирование файлов по-прежнему останавливается. Кроме того, dmesg теперь показывает критические ошибки во время операций TRIM/DISCARD при активном autotrim или во время записи:
* \[ 85.821360] sd 6:0:0:0: \[sda] tag#0 FAILED Result: hostbyte=DID\_OK driverbyte=DRIVER\_OK cmd\_age=0s
* \[ 85.821365] sd 6:0:0:0: \[sda] tag#0 Sense Key : Illegal Request \[current]
* \[ 85.821366] sd 6:0:0:0: \[sda] tag#0 Add. Sense: Logical block address out of range
* \[ 85.821368] sd 6:0:0:0: \[sda] tag#0 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
* \[ 85.821369] critical target error, dev sda, sector 1116008816 op 0x3:(DISCARD) flags 0x0 phys\_seg 1 prio class 0
* \[ 85.821371] zio pool=tank vdev=/dev/disk/by-id/usb-JMicron\_Tech\_DD56419883890-0:0-part4 error=121 type=6 offset=464021282816 size=40960 flags=524480 (Эти ошибки повторяются)
* **Текущее состояние:** Из-за этих ошибок UNMAP я временно отключил autotrim (zpool set autotrim=off tank) и удалил правило udev (/etc/udev/rules.d/90-usb-nvme-jms583-trim.rules, перезагрузил правила, повторно подключил устройство). Проблема со сбоями по-прежнему сохраняется.
* **Свойство ZFS sync для набора данных LXC:** zfs get sync tank/subvol-100-disk-1 показывает standard.
**Вопросы:**
* Учитывая ошибки "Logical block address out of range" во время операций DISCARD даже при DISC-MAX, не подтверждает ли это неисправленную реализацию TRIM/UNMAP во встроенном ПО моего корпуса Kinsound (JMicron JMS583) при использовании с Linux?
* Находил ли кто-нибудь надежное решение или обходной путь для этих конкретных ошибок UNMAP с устройствами 152d:0583 в последних Proxmox/Linux-ядрах, помимо стандартной правки provisioning\_mode udev?
* Могут ли сами неудачные команды UNMAP (когда была предпринята попытка TRIM) вызывать или усугублять сбои записи?
* Есть ли какие-либо другие настройки ZFS или параметры ядра, которые следует изучить для одноустрочного пула ZFS в Proxmox?
* Нужно ли искать другой корпус NVMe, например, с другим контроллером (ASMedia или другой)?
Буду благодарен за любые идеи или предложения. Спасибо!
