DAS: fouten over USB 3.1 maar niet over SATA

[Redsandro]

Voor het gebruiken van een grote dataset op een laptop heb ik de volgende Direct Attached Storage (DAS) aangeschaft: pricewatch: Fantec QB-35U31 Zwart

Het gaat om een ZFS pool met 4 schijven die samen een doorvoersnelheid van ~650 MB/s hebben, zoals ze nu aan een desktop hangen via SATA-600-verbindingen.

De 10 Gb/s van USB 3.1 type-C met UASP van deze DAS leek me daarvoor ideaal, want die kan aan een laptop worden aangesloten met nog genoeg bandbreedte voor overhead.

Om te testen heb ik de schijven uit de desktop gehaald, in de DAS gedaan, en aangesloten op diezelfde desktop via de USB 3.2 Gen2 Type C poort aan de achterkant. De kabel die ik daarvoor gebruik is de bij de DAS geleverde USB Type C kabel. Het gaat om dit moederbord: pricewatch: Gigabyte Aorus X570 I PRO WIFI

Tot mijn verbazing krijg ik allerlei schrijf- en checksumfouten, en dropt de performance soms tot 10 MB/s, om daarna weer naar 300 MB/s te gaan.

De ZFS pool gaat dan (steeds) automatisch resilveren, en dan blijkt dat er geen fouten waren. Hij hoeft nooit iets te herstellen.

Ik haal de schijven weer uit de DAS en sluit ze weer direct aan op SATA-kabels. En alle problemen zijn weer weg. De schijven zijn (bijna) nieuw en hebben 0 reallocated sectors en 0 errors in SMART staan.

Dat de performance misschien gehalveerd wordt, daar kan ik mee leven. Maar die extreme drops en al die fouten uiteraard niet. Dat is niet de bedoeling. En het ligt dus niet aan de schijven. Maar waaraan dan wel?

Is de (meegeleverde) kabel slecht? Is deze DAS geen serieuze hardware? Is mijn desktop testcomputer het probleem? Is dit een bekend verschijnsel bij een snelle USB-verbinding? (Ik heb hiervoor eigenlijk nooit 'echt' gebruik gemaakt van die snelle USB 3.2.)

Nu heb ik een USB-A naar USB-C kabel besteld, zodat ik het zelfde op een andere USB-poort of andere computer zonder USB-C-poort kan proberen, om te zien of het aan de kabel danwel de testcomputer ligt. Hopelijk komt deze kabel morgen binnen. Eerlijk gezegd lijkt het me sterk dat er een ondeugdelijke kabel met de DAS is meegeleverd, maar je weet het niet.

Ik ben even kwijt wat een handige volgende stap is. Wat kan ik doen? Zijn er dingen waar ik nog niet aan heb gedacht?

edit:

Instant update: De desktop draait Ubuntu 20.04.1. Kernel 5.4. Ruim nieuw genoeg om USB 3.2 en UASP te ondersteunen.

[dcm360]

Het zou kunnen dat dingen als sector-size door de behuizing anders worden doorgegeven dan dat ze direct gekoppeld aan een pc zijn. Je zou dus kunnen proberen om de pool te verwijderen (en het liefst ook de partitietabel), de schijven in de behuizing te stoppen en vervolgens weer een pool aan te maken. Als het dan nog mis gaat dan gebeurt er inderdaad iets vreemds.

[Anoniem: 567735]

Een paar algemene problemen worden ook hier besproken. Ik vermoed ook dat het een gebed zonder einde wordt via USB en dat je het nooit lekker aan de praat krijgt, want als het goed zou kunnen zouden de HBA-kaarten niet zo populair zijn

[Redsandro]

dcm360 schreef op donderdag 25 februari 2021 @ 18:09:
Het zou kunnen dat dingen als sector-size door de behuizing anders worden doorgegeven dan dat ze direct gekoppeld aan een pc zijn. Je zou dus kunnen proberen om (..) de schijven in de behuizing te stoppen en vervolgens weer een pool aan te maken.

Ik heb je advies opgevolgd, en helaas nog steeds het zelfde probleem. Inmiddels heb ik de laptop van mijn vriendin (die heeft USB-C) gestart met een bootstick, en daarop zijn er geen problemen! Wel een stuk trager (dan wanneer het op de desktop goed gaat).

Het vreemde is wel dat op de laptop de serial numbers van de schijven worden doorgegeven als 00000001, en de namen beginnen met "usb-". Op de desktop staan hier de echte serial numbers, en geen "usb-". Dus ik dacht dat de laptop misschien een andere verbinding.

Desktop:

code:

$ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 4: Dev 22, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 1: Dev 24, If 0, Class=Mass Storage, Driver=uas, 10000M
        |__ Port 2: Dev 25, If 0, Class=Mass Storage, Driver=uas, 10000M
        |__ Port 3: Dev 23, If 0, Class=Mass Storage, Driver=uas, 10000M
        |__ Port 4: Dev 26, If 0, Class=Mass Storage, Driver=uas, 10000M

Laptop:

code:

$ lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 10000M
    |__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 10000M
        |__ Port 1: Dev 4, If 0, Class=Mass Storage, Driver=uas, 10000M
        |__ Port 2: Dev 5, If 0, Class=Mass Storage, Driver=uas, 10000M
        |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=uas, 10000M
        |__ Port 4: Dev 6, If 0, Class=Mass Storage, Driver=uas, 10000M

Ze zijn dus wel allebei uas. Ik heb geen flauw idee waardoor dat verschil in schijf-aansluiting komt. Het enige dat ik zie is de Port direct onder de Bus. Die is bij de desktop 5000M, maar bij de laptop is alles 10000M.

Ik heb echter geen idee wat dit precies inhoudt, want de Bus zelf staat wel op 10000M. Volgens mij ben ik nu straws aan het graspen.

[Redsandro]

Anoniem: 567735 schreef op donderdag 25 februari 2021 @ 18:32:
Een paar algemene problemen worden ook hier besproken. Ik vermoed ook dat het een gebed zonder einde wordt via USB en dat je het nooit lekker aan de praat krijgt, want als het goed zou kunnen zouden de HBA-kaarten niet zo populair zijn

Interessant, bedankt voor de link. Ik wist niet dat HBA's nog een ding waren, anders dan het nog even upgraden van een verouderde computer.

[Q]

Als het op een andere computer wel goed werkt lijkt mij dat je misschien gewoon pech hebt met driver/hardware incompatibiliteit.

Doe je ook netjes telkens een export/import van de pool als je omwisselt?

Zie je foutmeldingen in /var/log/syslog?

[Thralas]

Redsandro schreef op donderdag 25 februari 2021 @ 19:02:
Het vreemde is wel dat op de laptop de serial numbers van de schijven worden doorgegeven als 00000001, en de namen beginnen met "usb-". Op de desktop staan hier de echte serial numbers, en geen "usb-". Dus ik dacht dat de laptop misschien een andere verbinding.

Waar zie je die serial numbers? Zou in ieder geval goed een udev-iets kunnen zijn. Zou er niet al teveel achter zoeken.

Ze zijn dus wel allebei uas. Ik heb geen flauw idee waardoor dat verschil in schijf-aansluiting komt. Het enige dat ik zie is de Port direct onder de Bus. Die is bij de desktop 5000M, maar bij de laptop is alles 10000M.

De hub is de DAS-device? Dan is het wel dubieus als hij blijkbaar geen 10000M linkspeed negotiate. Zou ik toch ook eens een ander kabeltje proberen.

Brakke kabels negotiaten ook een sub-par linkspeed is mijn ervaring (met 5000M vs 480M, that is). Maar als het op een andere machine wel werkt. Zeggen de kernel logs iets, bij inpluggen (linkspeed) of als het allemaal de soep in loopt?

Welke controller gebruikt die DAS? Controleer of daarover niets te vinden is. Er is een aardig lijstje aan blacklisted USB devices die UAS niet goed ondersteunen onder Linux. Meestal simpele single enclosures, maar toch.

De fallback daarvoor is mass storage mode, dat kun je ook nog even forceren ipv. UAS, om te kijken of dat helpt (zou wel impact kunnen hebben op performance).

[Voor 3% gewijzigd door Thralas op 25-02-2021 19:20]

[Redsandro]

Thralas schreef op donderdag 25 februari 2021 @ 19:19:
Waar zie je die serial numbers? Zou in ieder geval goed een udev-iets kunnen zijn. Zou er niet al teveel achter zoeken.

In /dev/disk/by-id/ en de disks-tool. Zou udev niet hetzelfde moeten aangeven aangezien ik nu op de laptop de zelfde linuxversie draai?

Dan is het wel dubieus als hij blijkbaar geen 10000M linkspeed negotiate. Zou ik toch ook eens een ander kabeltje proberen.

Brakke kabels negotiaten ook een sub-par linkspeed is mijn ervaring (met 5000M vs 480M, that is). Maar als het op een andere machine wel werkt. Zeggen de kernel logs iets, bij inpluggen (linkspeed) of als het allemaal de soep in loopt?

Kabeltje komt hopelijk morgen. Ik zal de logs bij het pluggen straks even checken, nu is hij weer even aan het benchmarken.

offtopic:
Ik check straks de rest van je reactie.

[Redsandro]

Thralas schreef op donderdag 25 februari 2021 @ 19:19:
Welke controller gebruikt die DAS? Controleer of daarover niets te vinden is. Er is een aardig lijstje aan blacklisted USB devices die UAS niet goed ondersteunen onder Linux.

Ik heb even gegoogled maar ik kan er weinig over vinden. UAS wordt vaak niet eens genoemd, maar ik ging er voor dat bedrag wel van uit (goed gegokt).

Volgens mij is zou het 2109:8822 moeten zijn.

De fallback daarvoor is mass storage mode, dat kun je ook nog even forceren ipv.

Heb je ook een idee hoe ik dat kan doen? Dan moet de DAS het kunnen, maar het zal wel verstandig zijn als die fallback erin zit.

[Redsandro]

Q schreef op donderdag 25 februari 2021 @ 19:17:
Doe je ook netjes telkens een export/import van de pool als je omwisselt?

Jazeker

Zie je foutmeldingen in /var/log/syslog?

Goeie, ik zie inderdaad steeds dit soort fouten:

code:

Feb 25 19:18:00: blk_update_request: critical target error, dev sdc, sector 1417541576 op 0x1:(WRITE) flags 0x4700 phys_seg 128 prio class 0
Feb 25 19:18:00: zio pool=pooltest vdev=/dev/sdc1 error=121 type=2 offset=725780238336 size=1048576 flags=40080c80
Feb 25 19:18:23: blk_update_request: critical target error, dev sda, sector 1254095328 op 0x1:(WRITE) flags 0x700 phys_seg 32 prio class 0
Feb 25 19:18:23: zio pool=pooltest vdev=/dev/sda1 error=121 type=2 offset=642095759360 size=131072 flags=180880
Feb 25 19:22:49: blk_update_request: critical target error, dev sdc, sector 1090189008 op 0x1:(WRITE) flags 0x4700 phys_seg 128 prio class 0
Feb 25 19:22:50: zio pool=pooltest vdev=/dev/sdc1 error=121 type=2 offset=558175723520 size=1048576 flags=40080c80

Alleen op de desktop, niet op de laptop.

[Thralas]

Redsandro schreef op donderdag 25 februari 2021 @ 23:30:
Ik heb even gegoogled maar ik kan er weinig over vinden. UAS wordt vaak niet eens genoemd, maar ik ging er voor dat bedrag wel van uit (goed gegokt).

Ja, zou zeker moeten werken. Maar dat is de theorie.

Heb je ook een idee hoe ik dat kan doen? Dan moet de DAS het kunnen, maar het zal wel verstandig zijn als die fallback erin zit.

Zo ongeveer, kernel boot argument:

code:

usb-storage.quirks=0x2109:0x8822:u

Maar dan even controleren welke vid/pid je moet hebben (lsusb?). Die 0x8822 lijkt me van de VL822, dat is een hub controller, niet een sata bridge.

Alleen op de desktop, niet op de laptop.

En de kernel log? Ik kan me niet voorstellen dat je alleen output ziet van zfs, maar niets van xhci/sd/uas.

[Redsandro]

Thralas schreef op vrijdag 26 februari 2021 @ 00:19:
[...]

En de kernel log? Ik kan me niet voorstellen dat je alleen output ziet van zfs, maar niets van xhci/sd/uas.

Nee, de kernel log laat precies hetzelfde zien. Alleen die fouten.

Thralas schreef op donderdag 25 februari 2021 @ 19:19:
[...]

Zeggen de kernel logs iets, bij inpluggen (linkspeed) of als het allemaal de soep in loopt?

Niet bij het in de soep lopen, maar bij het inpluggen wordt dit gelogged:

code:

Feb 26 01:31:40 usb 3-3: new high-speed USB device number 4 using xhci_hcd
Feb 26 01:31:40 usb 3-3: New USB device found, idVendor=2109, idProduct=2822, bcdDevice= 5.a3
Feb 26 01:31:40 usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 01:31:40 usb 3-3: Product: USB2.0 Hub
Feb 26 01:31:40 usb 3-3: Manufacturer: VIA Labs, Inc.
Feb 26 01:31:40 usb 3-3: SerialNumber: 000000001
Feb 26 01:31:40 hub 3-3:1.0: USB hub found
Feb 26 01:31:40 hub 3-3:1.0: 5 ports detected
Feb 26 01:31:40 usb 4-3: new SuperSpeed Gen 1 USB device number 7 using xhci_hcd
Feb 26 01:31:40 usb 4-3: New USB device found, idVendor=2109, idProduct=8822, bcdDevice= 5.a3
Feb 26 01:31:40 usb 4-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 01:31:40 usb 4-3: Product: USB3.1 Hub
Feb 26 01:31:40 usb 4-3: Manufacturer: VIA Labs, Inc.
Feb 26 01:31:40 usb 4-3: SerialNumber: 000000001
Feb 26 01:31:40 hub 4-3:1.0: USB hub found
Feb 26 01:31:40 hub 4-3:1.0: 4 ports detected
Feb 26 01:31:41 usb 3-3.5: new high-speed USB device number 5 using xhci_hcd
Feb 26 01:31:41 usb 3-3.5: New USB device found, idVendor=2109, idProduct=8818, bcdDevice= 0.01
Feb 26 01:31:41 usb 3-3.5: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 01:31:41 usb 3-3.5: Product: USB Billboard Device   
Feb 26 01:31:41 usb 3-3.5: Manufacturer: VIA Labs, Inc.
Feb 26 01:31:41 usb 3-3.5: SerialNumber: 0000000000000001
Feb 26 01:31:56 usb 4-3.3: new SuperSpeedPlus Gen 2 USB device number 8 using xhci_hcd
Feb 26 01:31:56 usb 4-3.3: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 6.14
Feb 26 01:31:56 usb 4-3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 01:31:56 usb 4-3.3: Product: USB3.1 SATA Bridge
Feb 26 01:31:56 usb 4-3.3: Manufacturer: VIA Labs,Inc.
Feb 26 01:31:56 usb 4-3.3: SerialNumber: 0000000000000003
Feb 26 01:31:56 scsi host7: uas
Feb 26 01:31:56 scsi 7:0:0:0: Direct-Access     TOSHIBA  HDWG180          0603 PQ: 0 ANSI: 6
Feb 26 01:31:56 sd 7:0:0:0: Attached scsi generic sg0 type 0
Feb 26 01:31:56 sd 7:0:0:0: [sda] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
Feb 26 01:31:56 sd 7:0:0:0: [sda] 4096-byte physical blocks
Feb 26 01:31:56 sd 7:0:0:0: [sda] Write Protect is off
Feb 26 01:31:56 sd 7:0:0:0: [sda] Mode Sense: 2f 00 00 00
Feb 26 01:31:56 sd 7:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 26 01:31:56 sd 7:0:0:0: [sda] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Feb 26 01:31:56  sda: sda1 sda9
Feb 26 01:31:56 sd 7:0:0:0: [sda] Attached SCSI disk
Feb 26 01:31:56 usb 4-3.1: new SuperSpeedPlus Gen 2 USB device number 9 using xhci_hcd
Feb 26 01:31:56 usb 4-3.1: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 6.14
Feb 26 01:31:56 usb 4-3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 01:31:56 usb 4-3.1: Product: USB3.1 SATA Bridge
Feb 26 01:31:56 usb 4-3.1: Manufacturer: VIA Labs,Inc.
Feb 26 01:31:56 usb 4-3.1: SerialNumber: 0000000000000001
Feb 26 01:31:56 scsi host8: uas
Feb 26 01:31:56 scsi 8:0:0:0: Direct-Access     TOSHIBA  HDWG180          0603 PQ: 0 ANSI: 6
Feb 26 01:31:56 sd 8:0:0:0: Attached scsi generic sg1 type 0
Feb 26 01:31:56 sd 8:0:0:0: [sdb] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
Feb 26 01:31:56 sd 8:0:0:0: [sdb] 4096-byte physical blocks
Feb 26 01:31:56 sd 8:0:0:0: [sdb] Write Protect is off
Feb 26 01:31:56 sd 8:0:0:0: [sdb] Mode Sense: 2f 00 00 00
Feb 26 01:31:56 sd 8:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 26 01:31:56 sd 8:0:0:0: [sdb] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Feb 26 01:31:56  sdb: sdb1 sdb9
Feb 26 01:31:56 sd 8:0:0:0: [sdb] Attached SCSI disk
Feb 26 01:32:00 usb 4-3.2: new SuperSpeedPlus Gen 2 USB device number 10 using xhci_hcd
Feb 26 01:32:00 usb 4-3.2: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 6.14
Feb 26 01:32:00 usb 4-3.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 01:32:00 usb 4-3.2: Product: USB3.1 SATA Bridge
Feb 26 01:32:00 usb 4-3.2: Manufacturer: VIA Labs,Inc.
Feb 26 01:32:00 usb 4-3.2: SerialNumber: 0000000000000002
Feb 26 01:32:00 scsi host9: uas
Feb 26 01:32:00 scsi 9:0:0:0: Direct-Access     WDC WD80 EFAX-68KNBN0     81.0 PQ: 0 ANSI: 6
Feb 26 01:32:00 sd 9:0:0:0: Attached scsi generic sg2 type 0
Feb 26 01:32:00 sd 9:0:0:0: [sdc] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
Feb 26 01:32:00 sd 9:0:0:0: [sdc] 4096-byte physical blocks
Feb 26 01:32:00 sd 9:0:0:0: [sdc] Write Protect is off
Feb 26 01:32:00 sd 9:0:0:0: [sdc] Mode Sense: 2f 00 00 00
Feb 26 01:32:00 sd 9:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 26 01:32:00 sd 9:0:0:0: [sdc] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Feb 26 01:32:00  sdc: sdc1 sdc9
Feb 26 01:32:00 sd 9:0:0:0: [sdc] Attached SCSI disk
Feb 26 01:32:06 usb 4-3.4: new SuperSpeedPlus Gen 2 USB device number 11 using xhci_hcd
Feb 26 01:32:06 usb 4-3.4: New USB device found, idVendor=2109, idProduct=0715, bcdDevice= 6.14
Feb 26 01:32:06 usb 4-3.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 26 01:32:06 usb 4-3.4: Product: USB3.1 SATA Bridge
Feb 26 01:32:06 usb 4-3.4: Manufacturer: VIA Labs,Inc.
Feb 26 01:32:06 usb 4-3.4: SerialNumber: 0000000000000004
Feb 26 01:32:06 scsi host10: uas
Feb 26 01:32:06 scsi 10:0:0:0: Direct-Access     ST8000NM 0055-1RM112      SN05 PQ: 0 ANSI: 6
Feb 26 01:32:06 sd 10:0:0:0: Attached scsi generic sg3 type 0
Feb 26 01:32:06 sd 10:0:0:0: [sdd] 15628053168 512-byte logical blocks: (8.00 TB/7.28 TiB)
Feb 26 01:32:06 sd 10:0:0:0: [sdd] 4096-byte physical blocks
Feb 26 01:32:06 sd 10:0:0:0: [sdd] Write Protect is off
Feb 26 01:32:06 sd 10:0:0:0: [sdd] Mode Sense: 2f 00 00 00
Feb 26 01:32:06 sd 10:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
Feb 26 01:32:06 sd 10:0:0:0: [sdd] Optimal transfer size 33553920 bytes not a multiple of physical block size (4096 bytes)
Feb 26 01:32:06  sdd: sdd1 sdd9
Feb 26 01:32:06 sd 10:0:0:0: [sdd] Attached SCSI disk

offtopic:
Is er geen collapse-UBB-code?

(Interessant die serienummers, zo zie ik ze dus op de laptop in de GUI ook, maar op deze desktop staan de serienummers in de GUI verder wel goed. Alleen in de log lijken ze wel al dan niet bewust automatisch te worden geanonimiseerd.)

[Thralas]

Redsandro schreef op vrijdag 26 februari 2021 @ 01:43:
Nee, de kernel log laat precies hetzelfde zien. Alleen die fouten.

Interessant. Je ziet dus geen errors van de lagere layers (xhci/uas), iets dat je eigenlijk wel zou verwachten als het een USB issue is. En critical target failure staat te boek als een permanente error; eerder als een SCSI command dat hij niet lust dan een tijdelijke write error. Maar de operation lijkt wel een write. Huh.

Zie ook dit stukje uit uas.c:

code:

    case RC_TMF_NOT_SUPPORTED:
        set_host_byte(cmnd, DID_TARGET_FAILURE);
        break;

Ik weet niet of er nog andere paden zijn, maar dat suggereert toch wel dat er op de één-of-andere manier een SCSI command tussendoor glipt dat om de een of andere reden niet geaccepteerd wordt.

Nu zou ik ook nog een slag om de arm houden als je niet zeker weet dat de I/O error ook de transfer speed issues veroorzaakt, maar het lijkt me in ieder geval niet de bedoeling. Voor deze issue lijkt me de handigste route om te kijken of je een capture kunt maken, misschien dat je daar uit kunt halen of de request anders is dan alle anderen; of dat er een duidelijkere error uit blijkt.

Zoiets, met het USB bus number als X, geen andere drukke devices op de bus:

modprobe usbmon
tcpdump -i usbmonX -s 9999 -w /tmp/uas.pcap -W 2 -C 256 

Dat schrijft naar twee roterende files van 256MB. Afhankelijk van hoe gemakkelijk je het kunt triggeren zul je even met de file count / size moeten spelen. En ik zou het op tmpfs zetten - in ieder geval niet op usb storage

[Redsandro]

Ik heb inmiddels de USB A naar C kabel ontvangen, en kan bevestigen dat het zelfde probleem zich op een (andere) USB 3.1 poort ook voordoet.

Verder heb ik met deze kabel een derde PC kunnen proberen, en daar doet het probleem zich niet voor. Deze PC is wat ouder, en de verbinding staat dus op 5000 M:

code:

$ sudo lsusb -t
/:  Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
    |__ Port 1: Dev 7, If 0, Class=Hub, Driver=hub/4p, 5000M
        |__ Port 1: Dev 9, If 0, Class=Mass Storage, Driver=uas, 5000M
        |__ Port 2: Dev 10, If 0, Class=Mass Storage, Driver=uas, 5000M
        |__ Port 3: Dev 8, If 0, Class=Mass Storage, Driver=uas, 5000M
        |__ Port 4: Dev 11, If 0, Class=Mass Storage, Driver=uas, 5000M

Ik weet nog steeds niet helemaal hoe ik dat moet lezen (e.g. is die tweede regel nu van de PC of van de DAS?), en ik weet niet in hoeverre het relevant of slechts een correlatie is, maar dit zijn tot nu toe mijn observaties:

10000M -> 10000M -> 10000M -> success
10000M -> 5000M -> 10000M -> errors
5000M -> 5000M -> 5000M -> success

Interessant is ook dat ik op deze PC geen SMART data uit kan lezen terwijl het wel gewoon UAS is, maar misschien heeft dat te maken met de versie van het systeem (Debian 9).

@Thralas interessante punten. Voor zekerheid: ik heb dus gekeken in syslog en kern.log. Ik weet niet of er nog andere plekken zijn waar ik eigenlijk ook even had moeten kijken.

Thralas schreef op vrijdag 26 februari 2021 @ 09:53:
[...]

modprobe usbmon
tcpdump -i usbmonX -s 9999 -w /tmp/uas.pcap -W 2 -C 256 

Dat schrijft naar twee roterende files van 256MB. Afhankelijk van hoe gemakkelijk je het kunt triggeren zul je even met de file count / size moeten spelen. En ik zou het op tmpfs zetten - in ieder geval niet op usb storage

Ik ken deze methode nog niet. Hoeveel data kan ik verwachten? Is dat (veel) meer dan over USB naar de DAS wordt gestuurd? Zovan, hoeveel tijd heb ik om een task te onderbreken als ik een fout in ZFS zie? Want we hebben het wel over een kleine burn-in test van 50 GB waarbij er structureel tussen de 10 en 200 errors langskomen. De eerste 2 GB gaan bijna altijd goed.

Overigens ben ik bang dat ik het nu even een weekje moet laten rusten, want de DAS is nu 'even' een pool aan het kopiëren die gerebuild gaat worden. Ik verwacht hooguit een week bezig te zijn (maar misschien 2 keer 2 dagen). Ik ben wel benieuwd of er een hele snelle hele kleine goedkope SSD is met UAS, zodat ik daarmee kan proberen of dit de zelfde problemen geeft.

[Thralas]

Redsandro schreef op vrijdag 26 februari 2021 @ 11:02:
Ik weet nog steeds niet helemaal hoe ik dat moet lezen (e.g. is die tweede regel nu van de PC of van de DAS?), en ik weet niet in hoeverre het relevant of slechts een correlatie is, maar dit zijn tot nu toe mijn observaties:

Die hub zit in de DAS. VL822.

Ik ken deze methode nog niet. Hoeveel data kan ik verwachten? Is dat (veel) meer dan over USB naar de DAS wordt gestuurd? Zovan, hoeveel tijd heb ik om een task te onderbreken als ik een fout in ZFS zie? Want we hebben het wel over een kleine burn-in test van 50 GB waarbij er structureel tussen de 10 en 200 errors langskomen. De eerste 2 GB gaan bijna altijd goed.

Overhead kun je negeren, maar dat wordt sowieso een flinke capture als je jezelf een seconde geeft om de capture te eindigen na een error.

Met dat hele duidelijke verschil tussen PCs twijfel ik wel een beetje aan de meerwaarde. Misschien dat er toch een USB link onstabiel is? Het vreemde is dat je geen resets van xhci oid. ziet.

Ik ben wel benieuwd of er een hele snelle hele kleine goedkope SSD is met UAS, zodat ik daarmee kan proberen of dit de zelfde problemen geeft.

Je kunt natuurlijk ook een goedkope USB<->SATA adapter zoeken met UAS. Die zijn er genoeg.

Uitdagender is wellicht USB 3.1 Type 2 - gezien het snelheidsverschil wil je waarschijnlijk wel testen met iets dat ook 10000M ondersteunt.

[FireDrunk]

Als je de disks lokaal in prikt geven ze dan ook een 4K block size? Hij geeft namelijk in de logs aan 512b logical, maar 4k physical, dat zorgt bij random IO voor wat delays omdat hij zelf de 512b IO's moet omzetten naar 4k acties. Dat zorgt voor wat meer queueing mogelijk, en dat zorgt op zijn beurt mogelijk voor wat gezever in de USB queues.

Je zou ook kunnen kijken of je je 10Gb setup die problemen geeft geforceerd op 5Gb kan draaien. Weet eigenlijk niet of dat kan hoor,

[Redsandro]

Even een kleine vertraging omdat ik de uitspraak van AMD wilde afwachten.

Inmiddels heb ik geverifieerd dat de ZFS-pool goed is, goede configuratie, prima werkt en volledig gescrubbed op 3 computers. Toevallig wel alle drie Intel.

Hij werkt dus niet op de 500-chipset van AMD. AMD ging er van uit dat dit om het zelfde probleem ging en gaf aan dat ze naar het probleem keken.

### Maar

Nu heb ik dus een MinisForum UM270 gekocht (AMD Ryzen 7 2700U). Geen flauw idee wat de chipset hiervan is, maar dat kan geen 500-series zijn. Echter heeft deze ongeveer precies het zelfde probleem.

Een scrub gaat na 10 minuten allerlei I/O fouten geven. En dan zijn opeens de UAS verbindingen weg.

Ingekort stukje logs:

code:

13:59:57 nas zed: eid=13 class=scrub_start pool_guid=0x2965B2F20651A54F  
14:08:39 nas kernel: sd 4:0:0:0: [sdd] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
14:08:39 nas kernel: sd 4:0:0:0: [sdd] tag#5 Sense Key : Illegal Request [current] 
14:08:39 nas kernel: sd 4:0:0:0: [sdd] tag#5 Add. Sense: Invalid command operation code
14:08:39 nas kernel: sd 4:0:0:0: [sdd] tag#5 CDB: Read(16) 88 00 00 00 00 01 72 09 02 c8 00 00 00 48 00 00
14:08:39 nas kernel: blk_update_request: critical target error, dev sdd, sector 6208160456 op 0x0:(READ) flags 0x700 phys_seg 9 prio class 0
14:08:39 nas kernel: zio pool=pool vdev=/dev/sdd1 error=121 type=1 offset=3178577104896 size=36864 flags=40080ca0
14:08:40 nas zed: eid=15 class=io pool_guid=0x2965B2F20651A54F vdev_path=/dev/sdd1 
14:12:44 nas kernel: sd 4:0:0:0: [sdd] tag#4 uas_eh_abort_handler 0 uas-tag 2 inflight: CMD IN 
14:12:44 nas kernel: sd 4:0:0:0: [sdd] tag#4 CDB: Read(16) 88 00 00 00 00 01 72 25 53 a8 00 00 00 48 00 00
14:12:49 nas kernel: xhci_hcd 0000:04:00.3: xHCI host not responding to stop endpoint command.
14:12:49 nas kernel: xhci_hcd 0000:04:00.3: xHCI host controller not responding, assume dead
14:12:49 nas kernel: xhci_hcd 0000:04:00.3: HC died; cleaning up
14:12:49 nas kernel: usb 1-1: USB disconnect, device number 4
14:12:49 nas kernel: usb 1-1.5: USB disconnect, device number 5
14:12:49 nas kernel: sd 4:0:0:0: [sdd] tag#3 uas_eh_abort_handler 0 uas-tag 1 inflight: CMD 
14:12:49 nas kernel: sd 4:0:0:0: [sdd] tag#3 CDB: Read(16) 88 00 00 00 00 01 72 25 52 98 00 00 00 38 00 00
14:12:49 nas kernel: sd 4:0:0:0: [sdd] tag#2 uas_eh_abort_handler 0 uas-tag 5 inflight: CMD 
14:12:49 nas kernel: sd 4:0:0:0: [sdd] tag#2 CDB: Read(16) 88 00 00 00 00 03 a3 80 e6 10 00 00 00 10 00 00
14:12:49 nas kernel: sd 4:0:0:0: [sdd] tag#1 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD 
14:12:49 nas kernel: sd 4:0:0:0: [sdd] tag#1 CDB: Read(16) 88 00 00 00 00 03 a3 80 e4 10 00 00 00 10 00 00
14:12:49 nas kernel: sd 4:0:0:0: [sdd] tag#0 uas_eh_abort_handler 0 uas-tag 3 inflight: CMD 
14:12:49 nas kernel: sd 4:0:0:0: [sdd] tag#0 CDB: Read(16) 88 00 00 00 00 00 00 00 0a 10 00 00 00 10 00 00
14:12:49 nas kernel: usb 2-1: USB disconnect, device number 2
14:12:49 nas kernel: usb 2-1.1: USB disconnect, device number 4
14:12:49 nas kernel: usb 1-3: USB disconnect, device number 2
14:12:49 nas kernel: sd 3:0:0:0: [sdc] Synchronizing SCSI cache
14:12:49 nas kernel: scsi host4: uas_eh_device_reset_handler FAILED to get lock err -19
14:12:49 nas kernel: sd 4:0:0:0: Device offlined - not ready after error recovery
14:12:49 nas kernel: zio pool=pool vdev=/dev/sdd1 error=5 type=1 offset=3032272011264 size=12288 flags=40080ca0
14:12:49 nas kernel: sd 4:0:0:0: rejecting I/O to offline device
14:12:49 nas kernel: zio pool=pool vdev=/dev/sdd1 error=5 type=1 offset=3032271814656 size=36864 flags=40080ca0
14:12:49 nas kernel: zio pool=pool vdev=/dev/sdc1 error=5 type=1 offset=3032271847424 size=8192 flags=1808a0
14:12:49 nas zed: eid=20 class=delay pool_guid=0x2965B2F20651A54F vdev_path=/dev/sdd1 
14:12:49 nas zed[10406]: Missed 1 events
14:12:49 nas zed: eid=124 class=io pool_guid=0x2965B2F20651A54F  
14:12:49 nas kernel: sd 3:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
14:12:49 nas kernel: xhci_hcd 0000:04:00.3: WARN Can't disable streams for endpoint 0x85, streams are being disabled already
14:12:49 nas kernel: usb 2-1.2: USB disconnect, device number 5
14:12:49 nas kernel: sd 4:0:0:0: [sdd] Synchronizing SCSI cache
14:12:49 nas kernel: sd 4:0:0:0: [sdd] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
14:12:49 nas kernel: xhci_hcd 0000:04:00.3: WARN Can't disable streams for endpoint 0x85, streams are being disabled already
14:12:49 nas kernel: usb 2-1.3: USB disconnect, device number 3
14:12:49 nas kernel: sd 2:0:0:0: [sdb] Synchronizing SCSI cache
14:12:49 nas kernel: zio pool=pool vdev=/dev/sdb1 error=5 type=1 offset=3032272310272 size=8192 flags=1808a0
14:12:50 nas kernel: sd 2:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
14:12:50 nas kernel: xhci_hcd 0000:04:00.3: WARN Can't disable streams for endpoint 0x85, streams are being disabled already
14:12:50 nas kernel: usb 2-1.4: USB disconnect, device number 6
14:12:50 nas kernel: sd 5:0:0:0: [sde] Synchronizing SCSI cache
14:12:50 nas kernel: zio pool=pool vdev=/dev/sde1 error=5 type=1 offset=3032266256384 size=8192 flags=1808a0
14:12:50 nas kernel: WARNING: Pool 'pool' has encountered an uncorrectable I/O failure and has been suspended.
14:12:50 nas kernel: sd 5:0:0:0: [sde] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
14:12:50 nas kernel: xhci_hcd 0000:04:00.3: WARN Can't disable streams for endpoint 0x85, streams are being disabled already
14:13:11 nas zed: eid=5182 class=io_failure pool_guid=0x2965B2F20651A54F  
14:13:39 nas smartd[3360793]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 43 to 44
14:13:39 nas smartd[3360793]: Device: /dev/sdb [SAT], removed ATA device: No such device
14:13:39 nas smartd[3360793]: Device: /dev/sdc [SAT], removed ATA device: No such device
14:13:39 nas smartd[3360793]: Device: /dev/sdd [SAT], removed ATA device: No such device
14:13:39 nas smartd[3360793]: Device: /dev/sde [SAT], removed ATA device: No such device

Vervolgens stopt de muis ook met werken, en worden nieuwe USB-apparaten niet gedetecteerd. Ik kan de DAS ook niet uit- en inpluggen. Hij blijft hangen als ik over ssh een reboot doe.

De enige manier om de MinisForum UM270 weer in een normale staat te krijgen is door hem hardwarematig te rebooten.

Inmiddels heb ik de DAS weer helemaal healthy door hem in mijn Intel-laptop te hangen en te scrubben.

Dit is wel erg opvallend, het gaat weer om een AMD. Maar ik weet niet wat de chipset van deze device is. En weet niet of ik hier bij AMD moet aankloppen of bij MinisForum. Dat laatste is lastig, een beetje een vaag forum lijkt de enige plaats en daar wacht ik op "moderator approval".

edit:

Also reported here.