Seagate Expansion Desktop Performance Drop nach 160GB

[LukeLR101]

Hallo zusammen,

ich benutze 4 externe Festplatten vom Typ "Seagate Expansion Desktop" mit 8TB über USB 3.0 an einem Linux-System, die ich zu verschiedenen Zeitpunkten, über die letzten zwei Jahre verteilt und bei verschiedenen Händlern, gekauft habe. Die sequenzielle Lesegeschwindigkeit der Festplatten ist mit ~180MB/s sehr gut - zumindest für die ersten ~160GB. Danach bricht die Geschwindigkeit auf ~20MB/s ein. Dies ist reproduzierbar, und tritt auch auf, wenn ich nicht am Anfang der Festplatte zu lesen beginne, sondern bei ~150GB. Dann tritt der Fehler bereits nach ~10GB gelesenen Daten auf. Es ist also nicht die Menge der gelesenen Daten das Problem, sondern die Position auf der Festplatte.

Gibt es jemanden, der schonmal von einem ähnlichen Problem gehört hat? Vielleicht sogar mit diesem Modell? Oder hat vielleicht jemand eine Idee, wie man das Problem weiter untersuchen / eingrenzen könnte? Gemessen habe ich die Werte mit:

sudo dd if=/dev/sdx1 of=/dev/null bs=4K status=progress
sudo dd if=/dev/sdx1 of=/dev/null bs=4K status=progress skip=37500000

der zweite Befehl überspringt die ersten 150GB, und fängt erst dann an zu lesen. Der Fehler tritt also direkt auf den Festplatten auf, unabhängig von einem Dateisystem o.ä.

Mich wundert sehr, dass der Fehler bei einer so breiten Stichprobe dieser Festplatten auftritt. Sonst wäre ich von einem Defekt der jeweiligen Festplatte ausgegangen, aber so erscheint mir dies sehr unwahrscheinlich. Danke für jegliche Tipps oder Hinweise!

 

[Nebula123]

Ich hatte jetzt mal auf SMR getippt.
Wenn der Cache und die CMR-Spuren (zum zwischenparken) voll sind bei hoher Schreiblast und direkt auf die SMR-Spuren geschrieben werden muss bricht die Geschwindigkeit massiv ein. Das tritt aber nur beim Schreiben auf, aber nicht beim Lesen.
Von daher bin ich jetzt etwas überfragt

 

[LukeLR101]

Hi! Ja, einen ähnlichen Gedanken hatte ich auch schon, bin aber zu demselben Schluss gekommen wie du: Die Schreibgeschwindigkeiten dürften dann einbrechen, ich sehe aber noch keine Erklärung, weshalb auch die Leseraten dann einbrechen würden.

 

[lokon]

Ist in den SMART-Werten der Festplatte etwas "seltsames" ?
Revision, Seriennummer, Fabrik (keine Ahnung ob die erkennbar im Serial/anderer Nummer kodiert ist) - welche "Jahre" betrifft das?

PS: Seagate kann UAS unter Linux - damit funktioniert smartmontools nicht - es muss usb-storage dafür verwendet werden (UAS blacklisten oder USB-Device für UAS blacklisten) [1]

Passiert der Bug auch bei USB-Storage Verwendung ?
USB-Ports wurden schon gewechselt ?
Im Kernel-Log gibt es keine USB-Fehler ?


[1] siehe https://www.smartmontools.org/wiki/SAT-with-UAS-Linux , Blacklisting via kernel cmdline: usb-storage.quirks=aaaa:bbbb:u
aaaa:bbbb = USB Device ID , "u" deaktiviert uas Modus

Die verschiedenen SMART Selbsttests (im alten usb-storage Modus) (short; evtl auch "long" , der braucht aber einige Stunden) laufen durch ohne Probleme im Smartlog ?


eher nicht: Ist die Platte "vibrationsgeschützt" ?

bei einer so breiten Stichprobe dieser Festplatten

In meiner Stichprobe ist alles in Ordnung.

Vendor:               Seagate
Product:              Expansion Desk
Revision:             0915
Compliance:           SPC-4
User Capacity:        8.001.563.221.504 bytes [8,00 TB]
...
Logical Unit id:      0x3e41385844585954
Serial number:        NA8XDXY

(mit UAS - bei bedarf kann ich auch in den Smartwerten umschaun)
S/N sagt beim Online RMA Check "Modellnummer STEB8000402" , mit Garantie bis Januar 2021 - dh. indirekter Rückschluß auf Herstellungsdatum ist auch möglich.

 

[LukeLR101]

Hi, danke schonmal für den Tipp mit den usbquirks! Das hat tatsächlich geholfen, ich musste nichtmal u verwenden, um UAS komplett zu deaktivieren, einfach 0bc2:331a:,0bc2:3322: zu spezifizieren hat gereicht, um den Standardwert t zu entfernen. Anschließend funktioniert hdparm und smartctl auf allen vier Platten

Gäbe es einen Grund, dass das positive Auswirkungen auf die Sync-Geschwindigkeit haben könnte? Ich probiere es gerade nochmal aus, jetzt läuft es gerade mit 20MB/s, was immer noch nicht die Performance von den ersten 80GB erreicht, aber ist schonmal besser als 8MB/s. Werde mal beobachten, ob das so bleibt.

Die Smart-Werte waren bisher unauffällig, die Platten sind auch alle recht neu, wurden bisher nur für einige Benchmarks verwendet. Im Kernel-Log sind keine Fehler aufgeführt, und die Platten hängen an verschiedenen Ports von verschiedenen USB-Controllern (1x Mainboard + 2 verschiedene PCI-Karten) sodass ich auch das als Fehlerquelle ausschließen würde. Falls die Performance wieder einbricht, werde ich mal einen Smart-Test machen.

Gibt es sonst ggf. die Möglichkeit, die Festplatten auf den Auslieferungszustand zurückzusetzen, also insbesondere die SMR-Controller darin? Vielleicht über einen TRIM-Befehl oder ATA Secure Erase oder sowas alle Daten als gelöscht markieren?

 

[Nebula123]

Sowas wie Trim gibt es imho auch bei SMR-Platten.
Secure Erase geht auch, ist aber extrem langsam (die ganze HDD wird verschlüsselt und dann der Schlüssel gelöscht, geht aber glaube ich nicht über USB.

 

[LukeLR101]

Der sync läuft immer noch, mittlerweile habe ich es sowohl mit 0bc2:331a:,0bc2:3322: als auch mit 0bc2:331a:u,0bc2:3322:u versucht, ohne Erfolg. Performance lag zwar zwischenzeitlich mal bei ~20MB/s, ist aber kurz darauf immer wieder auf 8MB/s zurückgefallen. Aller Vorraussicht nach wird der Sync auf diese Weise noch weitere 7 Tage dauern... Noch irgendwelche Tipps, wie man es vielleicht wenigstens ein bisschen beschleunigen kann?

 

[lokon]

Die Platten hängen an unterschiedlichen USB Bussen ?

lsusb -t

Bei "sync" mechanismen vielleicht irgendwie die Blockgröße / IO-Einheiten erhöhen ?

Ansonsten sind die Platten wohl "okay" - die Smart-Werte von Seagate, die für "Lesefehler" sind, SEEK_ERROR_RATE ist wohl nicht so aussagekräftig, und exotischere wie UDMA_CRC_Error_Count, Raw_Read_Error_Rate sind wie andere nicht so öffentlich dokumentiert - meist werden nur "fehlerhafte Sektoren" als Kriterium genommen, obwohl fehlerhaftes "Spurfinden" eine Ausfallerscheinung der Positioniermechanik sein könnte

 

[Inzersdorfer]

Au contraire, sowohl die Lese und Suchfehler als auch die CRC Fehler sind klar und aussagekräftig. Es gibt Übrigens einen eigenen Thread zu den SMART Werten im Unterforum Datenrettung, da wird einem geholfen wenn man sich nicht mit SMART-Werten beschäftigen kann oder möchte.