HDD-ul extern se demonta în continuare. Problema reală era altceva.

15 Aprilie 2026

Acum câteva zile scriam despre cum HDD-ul extern atașat la Intel NUC se demonta noaptea din cauza USB autosuspend - nucleul punea adaptorul JMicron JMS578 în sleep după câteva secunde de inactivitate, iar când încerca să scrie pe el, primea device offline error și demonta partiția de urgență. Am dezactivat autosuspend-ul printr-o regulă udev, am adăugat nofail în fstab și am crezut că am închis subiectul.

Azi dimineață, la 6:46, același scenariu. A treia oară în trei săptămâni.

Ce spuneau jurnalele de data aceasta

Primul lucru pe care l-am verificat a fost dacă regula udev era activă și dacă JMicron-ul avea power/control setat la on. Discul apărea în lsblk ca sdd, ceea ce confirma că se reconectase singur după demontat, iar fstab folosea UUID, nu device name - deci nu era nici problema cu schimbarea numelui. Pur și simplu nu era montat.

Am rulat sudo journalctl -b | grep -E "mnt-data|sdd|mount" și am găsit ceva ce nu observasem înainte. La momentul exact al demontării, în jurnal apăreau mesaje de genul acesta:

sdd: Failed to create/update device symlink ... ignoring: Inappropriate ioctl for device

Discul se deconecta și reconecta instantaneu - un reset cycle complet al adaptorului - iar udev nu reușea să creeze symlink-urile din /dev/disk/by-id/ pentru că adaptorul nu răspundea corect la anumite comenzi SCSI. Asta era un semnal clar că problema nu era la nivelul power management-ului, ci la nivelul driverului cu care nucleul comunica cu adaptorul.

UAS - driverul care creează probleme pe adaptoare ieftine

Kernelul Linux suportă două moduri de comunicare cu dispozitivele de stocare USB: BOT (Bulk-Only Transport), care e protocolul clasic și simplu, și UAS (USB Attached SCSI), introdus pentru performanță mai bună prin paralelizarea comenzilor SCSI și reducerea latency-ului. Pe hârtie, UAS e superior. În practică, multe adaptoare USB-SATA ieftine - inclusiv cele cu chipset JMicron JMS578 - au implementări firmware defectuoase ale UAS care duc la comportamente imprevizibile: reset cycles, erori de I/O sau, cum era cazul meu, demontări bruște.

Am verificat cu sudo dmesg | grep -i uas și răspunsul a fost imediat:

scsi host3: uas
scsi host2: uas
scsi host4: uas

Trei instanțe, câte una pentru fiecare reconectare a adaptorului din ultimele săptămâni. Nucleul detecta JMicron-ul, alegea UAS ca driver, pentru că adaptorul declara suport pentru el, și la un moment dat, în mod regulat, driverul intra în conflict cu firmware-ul adaptorului și provoca un reset.

Soluția: forțarea fallback-ului pe usb-storage

Linux are un mecanism de quirks prin care poți instrui kernelul să trateze anumite dispozitive diferit față de cum le-ar trata în mod normal, identificate prin idVendor și idProduct. Pentru a dezactiva UAS pe JMicron JMS578 și a forța folosirea driverului usb-storage (BOT), am creat un fișier de configurare:

sudo nano /etc/modprobe.d/usb-storage-quirks.conf

Cu conținutul:

options usb-storage quirks=152d:0578:u

Flag-ul u din lista de quirks înseamnă exact NO_UAS - nucleul va ignora faptul că adaptorul declară suport pentru UAS și va folosi în schimb usb-storage. Valorile 152d:0578 sunt idVendor:idProduct ale adaptorului, obținute cu lsusb.

Pentru ca modificarea să fie inclusă în initramfs și să se aplice la boot, înainte ca kernelul să încarce driverele USB, am rulat:

sudo update-initramfs -u
sudo reboot

După repornire, sudo dmesg | grep -E "uas|usb-storage|152d" a confirmat că totul funcționează corect:

usb 2-4: UAS is ignored for this device, using usb-storage instead
usb-storage 2-4:1.0: Quirks match for vid 152d pid 0578: 1800000

Ce am înțeles greșit în primul rând

Articolul anterior nu era complet greșit - USB autosuspend poate provoca exact aceleași simptome pe același tip de adaptor și rămâne o problemă reală pe sisteme unde discul stă inactiv ore întregi. Regula udev pentru power/control=on e în continuare validă ca măsură de precauție.

Dar cauza principală a reseturilor era UAS, nu autosuspend-ul. Cele două probleme pot coexista și se pot masca reciproc, mai ales că simptomele sunt aproape identice: device offline error, demontat brusc, reconectare imediată cu alt device name. Diferența e că autosuspend intra în acțiune după perioade lungi de inactivitate, în timp ce UAS putea provoca reset-ul și în mijlocul unei operații de scriere, ceea ce explica de ce problema persista chiar și după ce dezactivasem autosuspend-ul.

Dacă folosești un adaptor USB-SATA bazat pe JMicron JMS578 sau orice alt adaptor ieftin și ai probleme similare de stabilitate, primul lucru pe care ar trebui să-l verifici este dacă nucleul folosește UAS. Dacă da, dezactivarea lui prin quirks e simplă și din experiența mea rezolvă problema definitiv.