ADATA HD710 PRO/2TB funktioniert hier nur unter Linux nicht

Es handelt sich um eine externen Festplatte mit USB 3.2 Gen.1 Anschluss.
Die Platte ist im Auslieferungszustand NTFS formatiert. Unter Windows ist das Beschreiben und das Lesen von Dateien kein Problem und geht, wie bei meinen anderen externen Festplatten auch, zügig und problemlos. Mit dieser ADATA USB-HDD funktioniert das aber nicht unter Linux. Ich wollte unter Verwendung des mitgelieferten USB-Kabels an einem USB3 Anschluss von einer internen SSD einen ca. 190 GB großen Dateiordner auf die ADATA HD710 PRO kopieren. Veranschlagt wurden dafür anfänglich 34 Minuten. Ab ca. 7 GB Fortschritt fing die rote LED der Festplatte an zu blinken und die Transferrate brach ein, veranschlagt waren jetzt bereits mehr als 2 Stunden. Kürze Zeit später Dauerblinken der roten LED, veranschlagt werden jetzt 41 Stunden und laut Fortschrittsanzeige scheint nichts mehr zu passieren. Also den PC über Nacht angelassen. Am nächsten Tag blinke die rote LED immer noch und es war auch kein weiterer Kopierfortschritt ersichtlich. Also Platte abgezogen und Neustart. Daraufhin ist die Partitionstabelle defekt und auch Windows kann da nichts mehr reparieren. Ich habe die Platte reklamiert und vorab eine weitere ADATA USB-HDD bekommen. Was soll ich sagen, die neue Platte macht exakt das Gleiche - sowohl unter Manjaro als auch Mint und auch an verschiedenen PCs. Hat jemand eine Idee, was das sein könnte? Da ADATA Toshiba HDDs verbaut, hier noch die Angaben von hdparm

ATA device, with non-removable media
	Model Number:       TOSHIBA MQ04ABD200                      
	Serial Number:      51CNP3HZT
	Firmware Revision:  JT001U  
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
	Used: unknown (minor revision code 0x006d) 
	Supported: 10 9 8 7 6 5 
	Likely used: 10
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:    16514064
	LBA    user addressable sectors:   268435455
	LBA48  user addressable sectors:  3907029168
	Logical  Sector size:                   512 bytes
	Physical Sector size:                  4096 bytes
	Logical Sector-0 offset:                  0 bytes
	device size with M = 1024*1024:     1907729 MBytes
	device size with M = 1000*1000:     2000398 MBytes (2000 GB)
	cache/buffer size  = unknown
	Form Factor: 2.5 inch
	Nominal Media Rotation Rate: 5400
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	Advanced power management level: 128
	DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	NOP cmd
	   *	DOWNLOAD_MICROCODE
	   *	Advanced Power Management feature set
	    	Power-Up In Standby feature set
	   *	SET_FEATURES required to spinup after power up
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	WRITE_{DMA|MULTIPLE}_FUA_EXT
	   *	64-bit World wide name
	   *	IDLE_IMMEDIATE with UNLOAD
	    	Write-Read-Verify feature set
	   *	WRITE_UNCORRECTABLE_EXT command
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Segmented DOWNLOAD_MICROCODE
	    	unknown 119[6]
	    	unknown 119[9]
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	Phy event counters
	   *	Idle-Unload when NCQ is active
	   *	Host automatic Partial to Slumber transitions
	   *	Device automatic Partial to Slumber transitions
	   *	READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
	    	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Software settings preservation
	   *	SMART Command Transport (SCT) feature set
	   *	SCT Write Same (AC2)
	   *	SCT Error Recovery Control (AC3)
	   *	SCT Features Control (AC4)
	   *	SCT Data Tables (AC5)
	   *	reserved 69[1]
	   *	Extended number of user addressable sectors 
	   *	DOWNLOAD MICROCODE DMA command
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
	not	frozen
	not	expired: security count
		supported: enhanced erase
	408min for SECURITY ERASE UNIT. 408min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000039ac2c8b30b
	NAA		: 5
	IEEE OUI	: 000039
	Unique ID	: ac2c8b30b
Checksum: correct

Bei der verbauten Toshiba HDD soll es sich angeblich um ein SMR Drive handeln.

Ja das stimmt so. Die MQ04 Serie läuft mit SMR: MQ04 Series | Toshiba Electronic Devices & Storage Corporation | Asia-English

Das Problem bei dir ist tatsächlich SMR und hängt mit den Zeitüberschreitungen zusammen bei hohen Eingaben/Ausgaben auf der Platte. Das kann unter anderem mit dem Journal zu tun haben…

Ich habe peinlichst darauf geachtet keine SMR Platten zu kaufen, deswegen habe ich das Problem nie gehabt mit den Schreibverzögerungen, die sehr wohl bekannt sind und auf die SMR Technik zurückzuführen sind.

Was man machen könnte, ist zum Beispiel den Timeout erhöhen:

export device="sdX"
echo "3600" | sudo tee -a /sys/block/$device/device/timeout

und schauen ob es nun stabiler ist, aber ich vermute linux erkennt nicht, dass deine externe Festplatte SMR hat und schreibt normal. Wenn diese direkt anschließt würde es bestimmt stabiler laufen.

Versuch auch den Kernel zu wechseln…

Vielen Dank für deine Nachricht, die meinen Verdacht zu bestätigen scheint.
Ein kurzer Zwischenbericht. Ich habe auf der HDD zusätzlich eine ext4 Partition angelegt. Ursprünglich war ohnehin angedacht, auf der HDD auch meine Timeshiftsicherungen abzulegen. Bereits 15 Sekunden nach Beginn der Timeshiftsicherung fängt wieder die rote LED an zu blinken (über deren Bewandnis übrigens nichts in der Bedienungsanleitung zu lesen steht). Timeshift bleibt einfach stehen. Auch nach einem Abbruch der Timeshift Sicherung blinkt die rote LED unendwegt weiter und man kann sein System mit der angesteckter HDD nicht mehr herunterfahren. Bleibt nur, die Festplatte abzuziehen. Danach geht wieder das Spielchen mit der zerstörten Partitionstabelle los. Soweit zum Zwischenbericht. Danke auch für deinen Tipp mit dem Timeout, aber selbst wenn das klappen würde, wäre das keine vertretbare Problemlösung für mich, die ich mir unter Linux vorstellen könnte. Ein Kernel Wechsel kommt leider auch nicht in Frage, weil bei einigen der hier laufenden Optimus-Laptops ohnehin bei der 10er Reihe Sense ist und darunter liegende Versionen in der Vergangenheit andere Probleme brachten. Nun, ich habe noch 3 Wochen Zeit für eine erneute Rückgabe. Diese Zeit werde ich nutzen, um mit dem ADATA Support in Kontakt zu treten und um eine Lösung für Linux zu ersuchen. Und glaube mir bitte, ich werde da richtig Druck machen.

Mach das :laughing:

cat /sys/block/sdX/queue/zoned
lsscsi -g

Es könnte auch sein, dass hier ein Performence-Problem besteht. Beim SMR Platten kann es zu Leistungsverlusten kommen, wenn die physischen Sektoren und logischen Sektoren nicht dieselbe Größe haben. Normal wird 512 Bytes für die logischen Sektoren verwendet, aber wenn die physischen Sektoren eine Größe von 4096 Bytes dann kommt es zu Problemen bei SMR anscheinend. Das sollte man man beim formatieren angeben:

Überprüfen:

cat /sys/class/block/sdX/queue/physical_block_size
cat /sys/class/block/sdX/queue/logical_block_size

Mit physischer Blockgröße formatieren:

mkfs.ext4 -F -b 4096 /dev/sdX

Hier verlink dich mal hier weiter:

Danke für deinen Hinweis. Das gehe ich noch an - aber nicht mehr heute.
Ich melde mich eventuell morgen wieder, je nachdem, was an neuen Problemen gerade bei uns ansteht.

Das war wohl nichts. Ich habe mich vor 4 Tagen bei ADATA angemeldet, dort mein Problem dem Support per Mail beschrieben und auch ein Support Ticket erhalten. Bis heute habe ich nichts mehr von denen gehört. Ich habe die Hinweise von @megavolt abgearbeitet und es scheint so zu sein, das die HDD über einem Controller die interne Blockgröße auf HDD Standard übersetzt und man diesbezüglich wohl kaum etwas machen kann. Mein Fazit: Unter Windows keine Probleme aber unter Linux für mich völlig unbrauchbar. So einer Platte vertrauen ich keine Daten an. Ich habe die HDD bereits retourniert.

Für eine SMR-Platte ist das überschreiben und einfügen von Informationen in vorhandene Blöcke ein echtes Problem. Dateisysteme, die bei Daten oder Metadaten kurz zuvor geschriebene Bereiche ändern sind dabei eine große Last für die SMR Platte.
SMR kann kleinere Bereiche (Blöcke) nicht direkt überschreiben. SMR muß dann einen großen überlappenden Bereich von Blöcken lesen, ändern und neu schreiben. Das dauert. Bei geringem Datenaufkommen geht das. Für ein Backup nicht. Spätestens beim Überschreiben des Backups mit dem nächsten geht das schief.

Eine mögliche Lösung könnte ein Dateisystem sein, das mit CoW arbeitet. Das schreibt große fortlaufende Bereiche (chunks) ohne Änderungen an bereits geschriebenen Blöcken vorzunehmen. So was macht der SMR-Technik keine Probleme. Dann sollte auch ein Backup dorthin problemlos möglich sein. Auch mehrfach :wink:

z.B. btrfs oder andere Dateisysteme mit CoW-Technik (Es gibt sogar einen windows-Treiber für btrfs. Und btrfs ist echt robust)

Das könnte ich mir eventuell als Lösung für eine interne Festplatte vorstellen, aber nicht für eine externe Festplatte, die eventuell auch als Multimedia Zuspieler genutzt wird. Letztendlich muss das jeder selbst verantworten. Mir kommt jedenfalls keine SMR mehr ins Haus. :face_with_raised_eyebrow:

Ich würde hier weniger auf ein SMR-Problem tippen als auf ein UAS-Problem.

Bei mir laufen diverse SMR-Platten unter Linux völlig problemlos!

Viele USB-SATA Bridges funktionieren nicht gut mit Linux - besonders negativ fallen z.B. die Controller von ASmedia auf.

Poste mal die Ausgabe von ‘lsusb’ und suche im journal nach ‘UAS’ (USB Attached SCSI) und seltsamen Fehlermeldungen wie z.B.

[ 573.203294] sd 6:0:0:0: [sda] tag#29 uas_eh_abort_handler 0 uas-tag 9 inflight: CMD OUT
[ 573.203302] sd 6:0:0:0: [sda] tag#29 CDB: Write(10) 2a 00 00 4f a0 00 00 04 00 00
[ 573.205063] sd 6:0:0:0: [sda] tag#28 uas_eh_abort_handler 0 uas-tag 10 inflight: CMD OUT
[ 573.205070] sd 6:0:0:0: [sda] tag#28 CDB: Write(10) 2a 00 00 4f a4 00 00 04 00 00

Ich hatte aber auch schon Fehlermeldungen, die gar keinen sinnvollen Rückschluss auf ein Problem mit UAS zuließen und trotzdem damit zusammenhingen.

Die Lösung ware dann eine entsprechende Konfigurationsdatei unter /etc/modprobe.d oder ein Kernel-Parameter im Bootloader, der UAS für diese spezifische Festplatte deaktiviert.

Ich kann zwar keine Links posten - aber Google einfach mal nach:

If you have a Raspberry Pi 4 and are getting bad speeds transferring data to/from USB3.0 SSDs, read this

Gerne, aber nicht mehr in diesem Leben! Wie bereits gesagt, ich habe beide Festplatten inzwischen zurückgegeben und das Thema ist für mich beendet.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.