Dotaz: Odpojovani USB HDD od PC

[polo23]

Ahoj,
mam notebook, na kterem si chci udelat zalohu na externi USB disk. Delam to rsyncem. Kdyz pripojim SSD disk, tak to probehne OK. Kdyz pripojim plotnovy HDD, tak to po chvili padne a zaloha se neprovede.

rsync: [sender] write error: Broken pipe (32)
rsync error: error in socket IO (code 10) at io.c(849) [sender=3.2.7]
rsync error: received SIGUSR1 (code 19) at main.c(1613) [generator=3.2.7]


Mate nekdo podobnou zkusenost, pripadne vite jak to resit?

dmesg

[371795.602570] sd 0:0:0:0: [sda] Attached SCSI disk
[371810.131781] EXT4-fs (dm-3): mounted filesystem 51fa4187-1747-4181-a4fd-91176fe0cce6 r/w with ordered data mode. Quota mode: none.
[371897.424476] usb 2-2: USB disconnect, device number 8
[371897.424596] xhci_hcd 0000:00:0d.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
[371897.432502] EXT4-fs warning (device dm-3): ext4_end_bio:342: I/O error 16 writing to inode 47881519 starting block 2170779)
[371897.432537] Buffer I/O error on device dm-3, logical block 2170779
[371897.432538] EXT4-fs warning (device dm-3): ext4_end_bio:342: I/O error 16 writing to inode 47881850 starting block 3087235)
[371897.432550] Buffer I/O error on device dm-3, logical block 2170780
[371897.432552] Buffer I/O error on device dm-3, logical block 2170781
[371897.432551] EXT4-fs warning (device dm-3): ext4_end_bio:342: I/O error 16 writing to inode 47881934 starting block 1849045)
[371897.432563] Buffer I/O error on device dm-3, logical block 3087235
[371897.432565] Buffer I/O error on device dm-3, logical block 3087236
[371897.432571] Buffer I/O error on device dm-3, logical block 1849045
[371897.439264] Buffer I/O error on dev dm-3, logical block 16, lost async page write
[371897.439279] Buffer I/O error on dev dm-3, logical block 23, lost async page write
[371897.439280] Aborting journal on device dm-3-8.
[371897.439284] Buffer I/O error on dev dm-3, logical block 38, lost async page write
[371897.439287] Buffer I/O error on dev dm-3, logical block 44, lost async page write
[371897.439289] Buffer I/O error on dev dm-3, logical block 46, lost async page write
[371897.439291] Buffer I/O error on dev dm-3, logical block 52, lost async page write
[371897.439293] Buffer I/O error on dev dm-3, logical block 55, lost async page write
[371897.439295] Buffer I/O error on dev dm-3, logical block 56, lost async page write
[371897.439298] Buffer I/O error on dev dm-3, logical block 57, lost async page write
[371897.439301] Buffer I/O error on dev dm-3, logical block 64, lost async page write
[371897.439325] JBD2: I/O error when updating journal superblock for dm-3-8.
[371897.439328] EXT4-fs error (device dm-3) in ext4_reserve_inode_write:5801: IO failure
[371897.439411] EXT4-fs (dm-3): I/O error while writing superblock
[371897.439417] EXT4-fs (dm-3): Remounting filesystem read-only
[371897.772655] usb 2-2: new SuperSpeed USB device number 9 using xhci_hcd
[371897.789375] usb 2-2: New USB device found, idVendor=1058, idProduct=25a2, bcdDevice=10.34
[371897.789380] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[371897.789381] usb 2-2: Product: Elements 25A2
[371897.789382] usb 2-2: Manufacturer: Western Digital
[371897.789383] usb 2-2: SerialNumber: 57585432413133433043534A
[371897.790068] usb-storage 2-2:1.0: USB Mass Storage device detected
[371897.790197] scsi host1: usb-storage 2-2:1.0
[371898.817003] scsi 1:0:0:0: Direct-Access     WD       Elements 25A2    1034 PQ: 0 ANSI: 6
[371898.817248] sd 1:0:0:0: Attached scsi generic sg0 type 0
[371898.827709] sd 1:0:0:0: [sdb] 1953458176 512-byte logical blocks: (1.00 TB/931 GiB)
[371898.828017] sd 1:0:0:0: [sdb] Write Protect is off
[371898.828020] sd 1:0:0:0: [sdb] Mode Sense: 47 00 10 08
[371898.828318] sd 1:0:0:0: [sdb] No Caching mode page found
[371898.828319] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[371898.888408]  sdb: sdb1
[371898.888568] sd 1:0:0:0: [sdb] Attached SCSI disk
[371904.142565] EXT4-fs (dm-3): unmounting filesystem 51fa4187-1747-4181-a4fd-91176fe0cce6.
[371904.148306] buffer_io_error: 294 callbacks suppressed
[371904.148312] Buffer I/O error on dev dm-3, logical block 0, lost sync page write
[371904.148329] EXT4-fs (dm-3): I/O error while writing superblock

---

---

Odpovědi

[X]

Vidim pokazeny JBOD raid na externim disku(wtf?) sda a normalne pripojeny WD-cko Elements 25A2, sdb1.

[Peter Golis]

Kde tam je JBOD?

Pýtam sa pre kamaráta. Mne sa hlási aj LVM nad zakryptovaným diskom ako DM, takže ja odpoveď nepotrebujem. A kryptované externé disky sú hádam už štandard u ľudí čo si vážia svoje súkromné dáta.

Ale hento na prvý vyzerá ako klasický problém slabého napájania cez USB. Dúfam že to nie je RPi napájané z mobilovej nabíjačky.

[X]

Slepota, beru zpet..

[polo23]

Nemůže jít o problém s nedostatečným napájením ext. HDD z USB portu?

Je možné vyzkoušet chování při připojení HDD přes externě napájený USB HUB?

[Andrej]

Nemůže jít o problém s nedostatečným napájením ext. HDD z USB portu?

Těžko. Viz new SuperSpeed USB device v logu.

Být to před 10+ lety, taky bych podezíral USB 2.0 paskvil s nedostatečným napájením. Dnes už je taková věc nepravděpodobná.

[PetebLazar]

Já jsem tímto způsobem stejně se projevující chování (u několika různých ext. 2,5" HDD) takto vyřešil. Šlo o Supermicro MB pod Epyc Milan. USB 3.0 dle specifikace snad poskytne max. 0,9A, což není zase tolik.

Průměrnou spotřebu pro 2,5" 1TB HDD udává 1,5W, což moc neříká nic o spotřebě nárazové(špičkové). https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/product/internal-drives/wd-blue-hdd/product-brief-western-digital-wd-blue-mobile-sata-hdd.pdf

Spotřebu pro ext. HDD WDC ve specifikacích neuvádí. https://www.westerndigital.com/products/portable-drives/wd-elements-portable-usb-3-0-hdd?sku=WDBUZG0010BBK-WESN

Až mi dorazí USB tester zkusím svou domněnku ověřit měřením.

[Peter Golis]

Potom sa pochváľ či cez ten merák aj potečú dáta medzi počítačom a externým zariadením ktoré chceš odmerať.

[PetebLazar]

Tak to vypadá, že zrovna tento řeší pouze napájení a data údajně nepřenáší. Takže ten v tomto asi nepomůže, škoda má snad vyšší sample rate a mohl možná chytit i peaky spotřeby. Nevadí, pořízen byl primárně pro testování napájení skrze USB.

Údajně někdo(jiný zase ne) uspěl s FNISRI-C1, ale u něj to vypadá že prodej již skončil. https://www.reddit.com/r/UsbCHardware/comments/vxpt6w/power_meter_with_data/

[PetebLazar]

Tento by snad měl podporovat data passthrough, ale asi bude mít omezenou funkcionalitu. https://www.startech.com/en-us/cables/usbc-pwrtester?srsltid=AfmBOoqZedr4NMgjAy88YTo9SbDONDTXZt_adMZu2mm3MlduyLeQXOs0

[PetebLazar]

Takže je to trochu jinak. Ext. 2,5" HDD WDC Element 2TB se skrze FNIRSI FNB58 k počítači jako mass storage připojil, ale podle všeho pouze rychlostí USB 2.0. Naměřená rychlost oběma směry tak nepřekročila 43MB/s.

Špičková naměřená spotřeba dosahovala cca 3,3W (vcelku daleko od zmiňovaného maxima 4,5W .. 5V/0,9A pro USB3.0).

Element_2TB_FNB58.png

Při vyšším IO zatížení HDD (jeho maximem je snad na vnějším okraji cca 100MB/s) bych očekával spotřebu vyšší.

Pokud se mi pod ruku dostane výše zmiňovaný USB powermeter s data pass (údajně až 10Gbps) zkusím spotřebu při maximální IO zátěži přeměřit.

[Peter Golis]

2,5' 2TB, to vyzerá na SMR. Ak to nereportuje zóny do OS, tak to z svojej podstaty nemá ako dosiahnuť vysoký prietok mimo malých vyrovnávacích zón. On si to musí sám aj upratať.

[PetebLazar]

Je to využívané na lineární zápis velkých souborů na prázdný disk, takže tam by snad neměl šindelový zápis přinášet výkonnostní dopad.

[Peter Golis]

Skús si ten disk kompletne prepísať na blokovej úrovni napr. pomocou pv alebo dd (so status=progress), a pozri si od akého objemu dát sa začne spomaľovať zápis.

Teda ak to pripojíš cez USB3, na USB2 sa to nemusí vôbec prejaviť keďže ten je rádovo pomalší. Teda kľudne aj o dva rády. A nezapisuj tam binárne nuly, tie si môže disk odchytávať.

[PetebLazar]

Já výkon lineárního zápisu/čtení souborů u těchto HDD přes USB3.0 léta znám. Testů netreba.

[Peter Golis]

Mám ich tiež dobrú zbierku, rôznych výrobcov a rôznych modelov (dokonca z čias pred SMR). Ale najviac ma pobavil výkon lacného 2.5" SSD pripojeného cez USB3 to SATA prevodník, lineárny prepis nulami išiel rýchlosťou zbernice. Keď som ho lineárne prepisoval nejakými dátami (jedno či badblocks alebo random), tak výkon zaujímavo klesol po vyčerpaní obidvoch cache. A držal sa približne na výkone zodpovedajúcom bežným praktickým rýchlostiam USB2. Náhoda? Nemyslím si.

[PetebLazar]

To, že některé(většina?) SSD zapisují soubory s 0x00 obsahem rychle je velku známým faktem. Faktorem zrychlení je údajně profit z velmi účinné komprese při přenosech, ale hlavní může spočívat v tom, že takovýto obsah po kompresi klade minimální nároky na prostor v pseudo-SLC cache (vejde se ho tam skoro nekonečné množství) a skutečný fyzický tohoto zápis (z pohledu OS již hotov) se odehrává na pozadí již reálnou rychlostí odpovídající použité flash technologii a míře trimmingu.

Další možností (pouze teorie) by mohlo být, že otrimované bloky SSD již 0x00 obsahem disponují (k fyzickému zápisu stejného obsahu do sektoru by tudíž teoreticky nemuselo dojít). Toto ovšem naráží na to, že většina dnešních SSD používá transparentní FDE (Full Disk Encryption) což vylučuje, aby obsah buněk bloku po trimmingu měl přímo význam bloku samých 0x00 v jeho dešifrované podobě.

[Peter Golis]

Keby to bolo len kompresiou, tak by išiel na plný kotol aj deštrukčný zápis cez badblocks. Ale ten to spomalí ako hociktoré iné dáta. Nespomalí to len tradičný rotačák bez šindľového zápisu, alebo SLC SSD. Oboje je dnes už problém zohnať.

[PetebLazar]

MLC (2-bit/cell) byly také schopné přímého zápisu (poslední comsumer mohykán byl NVMe Samsung 970 Pro). V RAID0 se ze čtyř dalo vymačknout 10GB/s trvalého zápisu přes celou kapacitu.

Teď již SLC(pseudo?) dostupné SSD pouze pro enterprise řešení. Poslední z těch 1TB MLC 970Pro jsem kupoval v přepočtu cca 250USD, níže zmíněný 800GB Soligm stojí snad okolo 1000USD.

https://www.servethehome.com/solidigm-d7-p5810-800gb-write-intensive-pcie-gen4-nvme-ssd-review/

[pet I.]

Koupil jsem USB Hub s vlastnim napajenim a uz to funguje!! Dekuji moc za nasmerovani.

[GeorgeWH]

Ako to?! Ved Andrej povedal... 511155#7

[PetebLazar]

A neměl on tam nakonec totožnou odpověď? Předpokládal bych, že jde o projev opětovného připojení device po obnově jeho napájení ze strany USB portu.

Těžko. Viz new SuperSpeed USB device v logu.

[GeorgeWH]

Nerozumiem.

Ty si napisal, ci to nemoze byt problem s napajanim. Vsevedko Andrej protirecil, ze to sa dialo uz davno a ze dnes je tento problem neaktualny. OP potom potvrdil, ze to bolo napajanim...

[PetebLazar]

To měl být joke. Že i když tvrdil, že by to napájením být nemůže právě jeho úryvek z dmesg je patrně projevem dočasné ztráty a následné obnovy napájení(připojení) ext. HDD (ochrana před přetížením USB portu).

[Isthvan]

Zkusenost mam, ale nevim, jak presne jsem to vyresil. Mam k tomu totiz nekolik poznamek vetsinou s dovetkem, ze nefungovaly. Dve slibnejsi bez dovetku jsou a) vypnout standby pres hdparm/sdparm a b) polozit ten disk na stul rovne a nekroutit kabel. To prvni muze pomoct, pokud se disk odpojuje, protoze usne, zatimco rsync si pocita, co tam ma nasypat, to druhe, pokud jde o spatny kontakt (muzes zkusit jiny kabel, jiny konektor, pripadne jiny/zadny USB hub (nektere mrzke huby nejsou s to dodat dost proudu)).
Ten disk jsem nekolik let pouzival (nez zemrel), aniz by se odpojoval, talze neco nakonec zabralo, ale take jsem mezi tim 2x vymenil NTB.

[Isthvan]

Jeste dodam, ze problemovy disk byl Seagate v externim/portable provedeni, ktere jinak moc nekupuju, mam radsi ramecky bez disku, do kterych si disky bud koupim zvlast, nebo v nich rotuju 2.5" disky z vyrazenych NTB. U tech jsem si niceho podezreleho nevsiml.

[FF]

A není to prostě jen požkozený disk, vadný sektor? Tyhe 2,5" WD disky byly dost na prd, sám jsem jich pár (3ks) 1TB měl a dnes mám funkční už jen jeden a ten ani moc nepoužívám (není pod zátěží).

[Andrej]

Disk doporučuji reklamovat, je-li ještě v záruce. Nic jiného asi nevymyslíš.

Připomínám známou věc: plotnový disk na USB je třeba před jakýmkoliv zápisem tak na hodinu připojit (bez přílišného šetření energie, tedy tak, aby se točil) a nechat zahřát na stabilní provozní teplotu. Jestli se na ten disk dělají zálohy za studena, stylem připojím a kopíruju, na jeho životnost to má dost zásadní vliv. Překvapuje mě, že vůbec nějaký výrobce disků dává záruku na externí rotující disk na USB. Asi všichni doufají, že ho zákazníci nebudou opravdu používat.

Při dnešní kapacitě externích SSD, jejich parametrech (kdy na Thunderboltu dávají běžně přes 2 GB/s čtení i zápisu) a cenách představuje plotnový disk spíš víc starostí než užitku.

Jinak: Tohle je zase dotaz typu „všehno špatně“:

Delam to rsyncem.

Co garantuje během kopie rsyncem atomicitu a konzistentnost zdrojových dat? Ouha. Nic. „Zálohy“ pak postupně sbírají náhodné smetí.

EXT4-fs

Opravdu? Na zálohy? V roce 2025? Sbohem, data. Hele, celé tohle úsilí zjevně nefunguje, nic smysluplného nezajišťuje, na takové „zálohy“ se nedá vsadit ani zlámaná grešle. K čemu vůbec celá ta podivná rsync aktivita je? Když chci zálohy, dělám skutečné zálohy — atomické inkrementální snapshoty, kryté checksumy dat i metadat (end-to-end, od zdroje až po zálohu).

[polo23]

Drive jsem mel i jiny plotnovy disk a problem byl podobny. Taky se odpojoval. Pouzivam SSD a HDD z toho duvodu kdyby jedna technologie selhala, tak to prezije druha.

Jak mam teda delat zrcadlovou zalohu kdyz ne rsync?

Ktery FS teda doporucujes?

Predem diky za vyjadreni.

[pavele]

No a už jsi zkusil to externí napájení pro ten plotnový disk?

[polo23]

Nevim jak to myslis... Ja mam plotnovy USB disk a ten se po pripojeni k notebooku odpojoval. Kdyz jsem ho pripojil pres HUB, ktery ma to napajeni tak je to uz ok.

[Peter Golis]

Oni sa kedysi predávali USB káble tvaru Y, pchalo sa to do dvoch USB portov a zabezpečovalo to dostatočný prúd pre napájanie zariadenia ktoré si nevedelo vyjednať viac ako minimálku z portu. Ale je to dosť dávno čo som takú vec videl keďže výrobcovia dosiek zvykli na hulváta zdvíhať dodávanie prúdu a výrobcovia príslušenstva sa na to stále spoliehajú.

A ani koncovka USB-C negarantuje že si príslušenstvo korektne počas handshake vyjedná profil napájania. Veľa ľudí to riešilo presne tým USB portom s externým napájaním.

[cz_motyl]

DD,

zkuste toto:

do /etc/default/grub pridame do radku GRUB_CMDLINE_LINUX_DEFAULT text: intel_iommu=off

Priklad vysledku: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=off"

Aktivujeme prikazem: update-grub reboot

[GeorgeWH]

WUT?!

[PetebLazar]

Podle AI by mohlo jít o snahu vyloučit negativní dopad sdílené IOMMU Group u USB controlleru a jiného device určeného k passthrough do VM.

[GeorgeWH]

A to by sposobovalo nahodne odpajanie disku pri zatazi?

[PetebLazar]

To vůbec netuším, také mne zajímalo o jakou souvislost mezi disconnect USB a IOMMU off by mohlo jít. S ničím relevantnějším AI Goole nepřišla.

[cz_motyl]

Mám u mých zákazníků několik desítek NASek (s USB3 portem) s OMV, kde připojuji externí USB HDD. Pluginem jsem se snažil kopírovat obsah určitého adresáře. Disk se mi přitom odpojoval a nebo hlásil spousty erroru. A to třeba už při formátování XFS. A nebo to bylo bez chyb, ale kopírování bylo několikrát pomalejší. Nevím proč někde tak, jinde onak, asi to bylo závislé na konkrétním chipsetu desky. Každopádně, výše uvedeným nastavením jsem se zbavil VŠECH uvedených problémů při používání USB HDD...

[PetebLazar]

MB se mohou lišit například defaultním ne(povolením) VT-d(IOMMU) v BIOSu.

Je v jejich konfiguraci OVM použit KVM plugin, případně hostují se na OMV nějaké VM? Například reakce pod tímto videem zmiňuje možnost využít v OVM/VM passthrough.

[cz_motyl]

Všechny NASky mají VT-d v defaultu, tedy v dnešní době enabled. Žádnou virtualizaci na NASkách nevyužívám, ani docker. A přesto je ten parametr klíčový pro obyčejné používání USB HDD.

[PetebLazar]

Kdysi jsem se setkal pod Windows s podivným vlivem AVG na fungovaní virtualizace v rámci VirtualBoxu. S aktivním AVG běžely VM řádově pomaleji. Chování přisuzuji tomu, že rezidentní štít AVG testované .exe soubory snad nechával běžet ve virtualizovaném sandboxu. Takže patrně šlo o nějaký vzájemný zápas o zdroje s výsledkem děsivého zpomalení VM.