Ein liten oppfølgjar til postinga i september om problema med ytinga eg hadde med ein 2 TB Seagate-disk i Windows. Eg har kjøpt inn ein rimeleg Intel NUC som er sett opp som ein openmediavault-server. I maskin har eg installert nemnde 2 TB-disken og sett opp openmediavault på ein 8 GB-partisjon. I tillegg har eg kopla til eit par eksterne USB 3.0-diskar eg har hatt liggande. All ledig plass intern og eksterne diskar er sett opp som ved hjelp av LVM for å få samla all ledig diskplass i ei eining.

Når eg dreiv å kopierte data til mitt nye oppsett, la eg merke til at det lugga voldsomt etter at den interne disken på 2 TB var fyllt opp. Problema starta når data byrja å straume til ein Seagate 3 TB USB 3.0-disk. Eg sjekka systemloggen på serveren og la merke til at det med få minuttars mellomrom kom slike meldingar:

Dec 9 17:35:21 NUC kernel: [79979.708372] sd 2:0:0:0: [sdb] tag#29 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
Dec 9 17:35:21 NUC kernel: [79979.708400] sd 2:0:0:0: [sdb] tag#29 CDB: Write(16) 8a 00 00 00 00 00 30 a2 a8 00 00 00 04 00 00 00
Dec 9 17:35:21 NUC kernel: [79979.711949] sd 2:0:0:0: [sdb] tag#28 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
Dec 9 17:35:21 NUC kernel: [79979.711973] sd 2:0:0:0: [sdb] tag#28 CDB: Write(16) 8a 00 00 00 00 00 30 a2 a4 00 00 00 04 00 00 00
Dec 9 17:35:21 NUC kernel: [79979.715481] sd 2:0:0:0: [sdb] tag#27 uas_eh_abort_handler 0 uas-tag 8 inflight: CMD OUT
Dec 9 17:35:21 NUC kernel: [79979.715506] sd 2:0:0:0: [sdb] tag#27 CDB: Write(16) 8a 00 00 00 00 00 30 a2 a0 00 00 00 04 00 00 00
Dec 9 17:35:21 NUC kernel: [79979.718968] sd 2:0:0:0: [sdb] tag#26 uas_eh_abort_handler 0 uas-tag 7 inflight: CMD OUT
Dec 9 17:35:21 NUC kernel: [79979.718991] sd 2:0:0:0: [sdb] tag#26 CDB: Write(16) 8a 00 00 00 00 00 30 a2 9c 00 00 00 04 00 00 00
Dec 9 17:35:21 NUC kernel: [79979.722455] sd 2:0:0:0: [sdb] tag#25 uas_eh_abort_handler 0 uas-tag 6 inflight: CMD OUT
Dec 9 17:35:21 NUC kernel: [79979.722477] sd 2:0:0:0: [sdb] tag#25 CDB: Write(16) 8a 00 00 00 00 00 30 a2 98 00 00 00 04 00 00 00
Dec 9 17:35:21 NUC kernel: [79979.725956] sd 2:0:0:0: [sdb] tag#0 uas_eh_abort_handler 0 uas-tag 11 inflight: CMD OUT
Dec 9 17:35:21 NUC kernel: [79979.725978] sd 2:0:0:0: [sdb] tag#0 CDB: Write(16) 8a 00 00 00 00 00 30 a2 ac 00 00 00 04 00 00 00
Dec 9 17:35:21 NUC kernel: [79979.752362] scsi host2: uas_eh_device_reset_handler start

Google er som vanleg min ven. Eg fann fort ut at dette var eit kjent problem med visse chipset som Seagate har nytta på sine USB 3.0-kabinett som husar diskane. OpenSuse og mange andre har ei grei skildring på korleis du kjem rundt dette problemet.

I mappa /etc/modprobe.d/ laga eg fila blacklist_uas.conf. I fila la eg inn options usb-storage quirks=0bc2:231a:u. Talkombinasjonen i blått er idVendor (Seagate RSS LLC) og idProduct (Expansion Portable). Du kan finne IDen ved å køyre lsusb -v | less. Endinga | less har eg lagt til for at du skal kunne trykke deg gjennom det som kjem frå kommandoen lsusb -v, som er side opp og side ned med informasjon frå alt som er relatert til USB. Til slutt køyrde eg initramfs -u og restarta maskina.

No har kopieringa stått på eit par timar, og systemloggen inneheld ikkje lenger meldingar som referert over. Endringa påverkar ikkje farten. I skrivande augeblikk ligg den på 102+ MB/sek og er dønn stabil.