ubuntuusers.de

Ich wurde von einem Freund um Hilfe gebeten, der eine Fehlermeldung mit gparted erhalten hat. Er hat mir Screenshots geschickt, aber nicht die Details. Grummel. Viel mehr als, dass es nicht funktioniert hat, kann ich nicht erkennen.

Ich möchte nun probieren ihm mit einem Konsolenbefehl zu helfen, bin mir da aber nicht so sicher. Mit gparted hat das ewig gedauert, vielleicht 20h.

Ich denke man erstellt zuerst eine gpt-Partitionstabelle, dann sollten die alten Partitionen weg sein, oder?

Wie erstelle ich die Partitionstabelle alleine?

Ich verwende normalerweise diese Befehle:

Bewirkt "optimal" ein 4k-Alignment?

parted /dev/sde -s -a optimal mklabel gpt mkpart primary 1 100%

Macht es Sinn vielleicht eine kleine Testpartition zu erstellen? Also statt 100% 5%?

Eigentlich will er letztlich eine LUKS-Partition erstellen, ist das folgende dann überhaupt notwendig? Macht es Sinn das zu probieren, ob die neue HDD vielleicht einen Fehler hat? Der Smart-Test ist ok.

mkfs.ext4 -v -L "TESTING" /dev/sde1

Hallo glaskugel, da schon Fehler vorliegen und auch GPARTED wohl Probleme hat, sollte man erst einmal den S.M.A.R.T Status abfragen… GSMARTCONTROL

Klappt das nicht, da das 10TB an einem ext.USB-HDD hängt und der Kontroller das nicht macht, muss das Laufwerk umgebaut werden.

Erst wenn ein Kurztest erfolgreich war, kann man weiter machen.

BYE HS

Erst wenn ein Kurztest erfolgreich war, kann man weiter machen.

Hatte ich wohl missverständlich geschrieben.

Der Smart-Test ist ok.

Hier gibt es Details:

smartctl 7.2 2020-12-30 r5155 [x86_64-linux-6.2.0-36-generic] (local build)

=== START OF INFORMATION SECTION ===
Device Model:     ST10000NM017B-2TL103
LU WWN Device Id: 5 000c50 0faa0f2c2
Firmware Version: SN03
User Capacity:    10.000.831.348.736 bytes [10,0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   ACS-4 (minor revision not indicated)
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sat Feb 15 15:29:27 2025 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled


SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   100   100   044    Pre-fail  Always       -       29810
  3 Spin_Up_Time            0x0003   093   093   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       6
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   067   060   045    Pre-fail  Always       -       5265049
  9 Power_On_Hours          0x0032   100   100   000    Old_age   Always       -       15
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       6
 18 Unknown_Attribute       0x000b   100   100   050    Pre-fail  Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   093   093   000    Old_age   Always       -       25770196999
190 Airflow_Temperature_Cel 0x0022   074   042   000    Old_age   Always       -       26 (Min/Max 24/26)
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       2
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       10
194 Temperature_Celsius     0x0022   026   058   000    Old_age   Always       -       26 (0 23 0 0 0)
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   100   000    Old_age   Offline      -       13 (169 73 0)
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       0
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       29810

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
# 1  Extended offline    Completed without error       00%        13         -
# 2  Short offline       Completed without error       00%         0         -

SMART Selective self-test log data structure revision number 1
 SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Ich frage mich zwar was man da bei gparted falsch machen kann, dass es zu einem Fehler kommt, aber vielleicht doch.

PS. Das Gehäuse ist ein Fantec DB-ALU31: https://www.fantec.de/en/products/storage-devices/ssd-hard-drive-cases/35-inch-hard-drive-cases/produkt/details/artikel/1973_fantec_db_alu31_2023/ (und ja ich weiß, dass du mit Fantec viele Probleme kennst, meine Fantec funktionieren zumindest grundsätzlich)

echo "obase=16; 25770196999" | bc | cut -c8-
07

Das ist aber schon bemerkenswert bei "Command_Timeout". Es gab 7 Timeouts. Problem der HD oder des Gehäuses?

Hallo glaskugel, einen COMMAND TIMEOUT… schwer zu definieren… möglicherweise wurden die Zeitdaten in einem Logbuch eingetragen… fanden diese innerhalb der letzten Zeit kurz hintereinander statt, dann einen erweiterten Testlauf mit S.M.A.R.T aktivieren… wird ca. 10 Std. dauern bei 10TB.

WIR machen das immer so:

Kurztest im originalen Gehäuse… ist dieser fehlerlos aber trotzdem unklare Effekte, dann ausbauen der HDD und an die DOCKING-Station… ERWEITERT TESTEN… klappt es, dann wird einfach das Gehäuse getauscht… und erneut geprüft… besteht Datenverlust, dann schicken wir das Teil sofort ins Rettungszentrum nach Ingolstadt… in der Zwischenzeit bekommt der Kunde ein neues System und seine geretteten Daten etwas später.

Das funktioniert natürlich bei Privat-Personen so nicht… logo… da muss aber der Inhaber entscheiden was ihm seine Daten wert sind.

WIR gehen da KEIN RISIKO ein… kostet manchmal zuviel!

BYE HS

da muss aber der Inhaber entscheiden was ihm seine Daten wert sind.

Das ist ein nagelneues Gehäuse und noch nie mit eigenen Daten beschriebene HDD.

Es gibt noch eine 2. HD von diesem Typ und weitere Gehäuse sind bestellt. Ist ein bisschen stressig mit der Rückgabefrist.

Ich tu mich ein bisschen schwer, weil ich es nicht selber gemacht habe. Aber es gab schon Probleme beim Erkennen der HD. Dauerte einige Zeit bis sie erkannt wurde, weiß nicht was "blau blinken" bei Fantec bedeutet. Jedenfalls muss es konstant blau blinken.

Vielleicht können wir zu parted und co zurück kommen. Sind meine Konsolenbefehle verbesserungswürdig?

dann einen erweiterten Testlauf mit S.M.A.R.T aktivieren… wird ca. 10 Std. dauern bei 10TB.

Die goposteten Smart-Werte stammen kurz nach dem langen Test. Da keine Partition angelegt, gab es nur Reboots und irgendwelche Abfragen.

Wir haben auch noch die Smart-Werte nach dem kurzen Test. Muss ich nachfragen.

Frage: Was bedeutet Selbsttest?

Wenn die "Command_Timeouts" beim Selbsttest entstanden sind, dann kann das Gehäuse nicht schuld sein. Mir wurde aber immer wieder berichtet, dass die HDD nicht erkannt wurde, worauf ich reboot empfahl. Es muss also nicht mit dem langen Test zusammenhängen.

Ich denke wir nehmen die 2. HD und machen da die Tests im gleichen Gehäuse.

Hallo glaskugel, ok, also mit GPARTED kann man das passend einstellen… GPT ist bei dieser Kapazität klar… der Selbsttest wird von der HDD selbst durchgeführt… z.Zt. bzw. in der letzten Zeit sind bei SEAGATE sehr viele Produkte als Fake verfügbar… dummerweise sind die Daten nicht direkt mit GSMARTCONROL einsehbar… es kann also sein, dass man eine HDD mit 0 Std. Laufzeit hat und real schon 20.000 Std..

Das kann man mit einem speziellen SEAGATE Tool auslesen lassen… keine Ahnung wie sich das nennt.

FANTEC… na ja, haben wir aufgegeben… hatten 100% Ausfall an den Gehäusen… Lüfter fielen aus und nach einigen Monaten Betrieb waren dann die HDD drin so heiss, das man braten konnte… diese Laufwerke waren damals ALLE mit vielen Fehlern behaftet… nicht gesund.

Mit WD gab es schon einmal ähnliche Probleme mit Laufwerken aus der GOLD-Klasse… kostet etliches so ein Teil… von 4 gekauften GOLD-HDD (8TB) waren nach 4-8 Mon. 3 hinüber… jedesmal einsenden nach CZ ans Prüfwerk und jedesmal hat es 5 WOCHEN gedauert bis ein REFURBISHED Ersatz kam - NEIN, KEIN Neuprodukt. Auch ein Hersteller den man anpissen sollte.

I.M. sind alte Medien von HGST und neue von TOSHIBA am verlässlichsten. Wir haben einen NAS draussen der seit 2013 mit 4x 1TB HDD von HGST arbeitet… 24x7… KEINEN DEFEKT… läuft einfach… cool.

Ja, teste es mit einem 2. Laufwerk aus.

BYE HS

Meine neueste Überlegung ist USB-Kabel tauschen und USB-Port auch wechseln. Aus der Ferne ist alles schwierig, aber ich selber hatte schon extreme Probleme mit USB-Kabel, die so halb kaputt waren Es ist ziemlich schwierig zuverlässig was gutes zu bekommen, ist Glücksspiel. Mit meinen Syncwire-Kabel bin ich sehr zufrieden, sind aber nicht mehr lieferbar, zumindest nicht in 1m, eine Zeit lang gab es die noch bei Amazon UK.

Also ich erinnere mich an Merkwüürdigkeiten mit dem Kabel wie mir berichtet wurde. Es gibt auch eine 6TB-HD in einem Fantec-Gehäuse, interessanterweise funktionierte das 1 Kabel nicht mit der anderen HD und umgekehrt. USB-C / USB-C und USB-C/USB-A probiert.

Gekauft wurde bei einem Schweizer Konzern, der direkt vom Lieferanten versandte, eventuell direkt von Seagate selbst. Das war kein kleiner Händler, der irgendwo güsntig Fakes kaufte. Das sind professionelle HDs, die eigentlich schon eine gewisse Qualität haben sollten, jedenfalls "non shingled / CMR". Beim Amazon Marketplace gab es deutlich günstigere Angebote von einem Händler mit eher schlechten Krtiken, da wurde lieber 50€ mehr pro Stück bezahlt.

Übrigens vorher entdeckt:

https://www.disktuna.com/seagate-raw-smart-attributes-to-error-convertertest/#25770196999 Result: 6 errors in 393.223 operations

Zeigt 1 Fehler weniger an, als meine Berechnung, ist aber nebensächlich.

FANTEC… na ja, haben wir aufgegeben… hatten 100% Ausfall an den Gehäusen… Lüfter

Dieses Gehäuse hat keinen Lüfter und lt. Smart ist die Temperatur ok, aber bei einem alten Fantec ist bei mir auch der Lüfter eingegangen. Mich hat bei Fantec vor allem genervt, dass es alle Augenblick neue Meodelle gab und man neue Gehäuse kaufen musste. Weiß nicht mehr was mich bei ICY störte, vielleicht zu viele negative Kritiken und mangelnde Angaben bei den Spezifikationen. Wie immer Bananen-Ware, der Kunde macht den Endtest.

Mit WD gab es schon einmal ähnliche Probleme

Heute gehören die früheren Hersteller irgendwie alle zusammen.

I.M. sind alte Medien von HGST und neue von TOSHIBA am verlässlichsten

Habe ich einige, aber meine Toshiba sind eher langsam, reichen aber zum TV aufnehmen in einer Enigma-Box. Leider gibt es die nicht mehr.

Bei HGST ist das auch so eine Sache, habe ich auch.

WD habe ich abgelehnt, weil Tod by Design. Weiß jetzt die Werte nicht mehr genau, wenn WD die HD alle 6 Sekunden (nicht änderbar) in den Schlaf schickt und Linux alle 8 Sekunden synct und aufweckt, dann ist der Tod vorprorammiert. Seagate hatte das damals nicht. Ich bin bei den Profi-Seagate-HDs gelandet, ist aber reines Bauchgefühl.

nach CZ ans Prüfwerk und jedesmal hat es 5 WOCHEN gedauert bis ein REFURBISHED Ersatz kam - NEIN, KEIN Neuprodukt>

So ähnlich kenne ich das auch, musste damals auf eigene Kosten einige Seagate(?) nach Irland schicken, weil smart sehr viele Fehler zeigte. Wurden problemlos getauscht, bekam dann refurbished mit noch schlechteren Werten. Außer Spesen und viel Zeit nichts gewesen.

Ich hatte damals die HDs mit badblocks überschrieben, aber wenn da noch Daten darauf sind, dann will man die in der Regel nicht wegschicken. Also Garantie und "Enterprise" ist für mich nur ein Indiz, dass die besser geprüft wurde, vielleicht ist der Mehrpreis auch nur eine Art Versicherung im Vergleich zu einer normalen und von der Produktion nur wenig besser.

Ja, teste es mit einem 2. Laufwerk aus.

Bevor die neuen Kabel nicht da sind, bleibt es beim alten Stand. Wir beobachten die Smart-Werte. Ich weiß noch nicht, wie es sich verändert hat, nachdem da ewig die Partition angelegt wurde. Vielleicht kriege ich heute noch ein paar Vergleichsdaten.

Hallo glaskugel, in der Technikbranche ist alles immer mehr Glückssache… es ändert sich zu schnell und verantwortungsvolle Qualität bleibt auf der Strecke. Der Käufer ist der TESTER… nicht mehr und nicht weniger.

Ich hatte seit Ende September 2024 mit einem leistungsfähigen Rechner das seltsamste Problem - bisher nicht gefunden… es ist aber spezifisch mit einem ASUS Mainboard XM670E-E und AMD Ryzen 9 der Fall… es wird mehrmals die Woche einfach so, aber immer am vormittag einfach der Rechner grundlos neu gestartet… der Start geht schnell und dauert typ. 30 Sek. …in verschiedenen Portalen sind ähnliche Meldungen von fast über 4000 Personen… Ursache bisher mit keinem BIOS behoben… egal wie das BIOS eingestellt wird… absolut sporadisch, man kann nichts festes erkennen.

Tatsache ist, dass man im Linux Logbuch findet, dass die INTERNE Uhr in diesen 30-40 Sek. Neustart zwischen 60-90 Min. schneller gelaufen ist… Linux stellt das dann zwar zurück, aber das ist das einzigste Merkmal.

Haben Anfang Februar diesen Rechner zum Hersteller zurück gesendet… man hat mitgeteilt, dass die Testzeit mind. 30 Tage dauert.

Technik ist ein Witz… witzigerweise passiert das bei diesem Mainboard nur beim Einsatz von AMD Ryzen 9… ein anderer Rechner mit AMD Ryzen 7 und dem gleichen Mainboard, identischer RAM, BIOS usw. macht das nicht. Mehrere tausend male gemeldet, vor allem von Gamern.

Technik wird immer schlimmer… juhu, und die KI gibt uns den Rest. 😉

BYE HS

Technik wird immer schlimmer… juhu, und die KI gibt uns den Rest

Ja, ich habe auch so einige Probleme mit Asus, Asrock und auch MSI seit vielen Jahren. Das MSI-UEFI-Bios hat 2 Jahre gebraucht, bis ein Bug behoben war und noch immer wird die Hardware nicht richtig erkannt (man muss probieren bis es funktioniert). Es wurde dann eher zufällig entdeckt, dass die Probleme von früher weg waren. Würgaround hatte ich gefunden, nur reklamieren ist da ziemlich sinnlos. Wer nur 1 PC hat, ist sowieso verloren. Meine / unsere hauptsächlich genutzten PCs sind mittlerweile Beelink-Minipcs, die reichen für sehr viel und wenn die zu schwach sind, setzen wir uns vor einen großen Midi-Tower. Da gibt es dann auch zig TBs.

Ich habe seit einigen Jahren ein Problem mit Asus-UHD-Monitoren und eigentlich nur mit diesen UHD, die ProART sind aber hier die besten "bezahlbaren" um die 1k, werden aber nur Fotobearbeitung benötigt. Manchmal sehe ich ein Login, oft nicht, mit viel Glück kommt es nach einer 1/2h oder länger. Passiert bei 2 Asus ProArt UHD; Viewsonic UHD hat kein Problem und mehrere Benq UHD auch nicht.

Zufällig habe ich jetzt entdeckt, wenn ich an den Asus UHD via DP anschließe (via UHD HDMI sind die Probleme ein wenig geringer, aber geauso existent) und gleichzeitig einen Asus HD, dann kann ich mich über den HD einloggen, während der UHD kein Login zeigt. Nach dem Login, zeigt auch der UHD ein Bild aber Richtung rechts ist nach ca. 2/3 die Maus nicht mehr bewegbar. Habe noch keine Zeit gefunden, das zu diskutieren. Aber zur Not, habe ich einen workaround mich anzumelden, ist nicht immer so, dass ich mich nicht anmelden kann, aber sehr häufig. Monitor immer im Standbye lassen verringert die Probleme, ist aber auch keine Garantie. Es wird einfach das Signal nicht gefunden. Also über HD anmelden, HD aus und über UHD Neustart klappt dann meistens, ist aber nervig.

Ein bisschen weiter sind wir schon, aber noch immer keine plausible Erklärung für "Command_Timeout"

vor kurzem Smart-Test;

Result: 3 errors in 196.612 operations.

Nach langem Smart-Test

Result: 6 errors in 393.223 operations

Nach fehlgeschlagenem gparted

Result: 1.351 errors in 88.540.494 operations.

Offensichtlich gab es da schon Probleme von Anfang an, aber nach gparted (Anlegen der Partition) sind sie extrem gestiegen, von ein paar auf über tausend.

Im root-Verzeichnis wurde gparted-Details gefunden:

GParted 1.3.1

configuration --enable-libparted-dmraid --enable-online-resize

libparted 3.4

========================================
Device:	/dev/sde
Modell:	asmedia ASM235
Sektorgröße:	512
Sektoren insgesamt:	19532873728
 
Köpfe:	255
Sektoren/Spuren:	2
Zylinder:	38299752
 
Partitionstabelle:	gpt
 
Partition	Type	Start	End	Markierungen	Partition Name	Dateisystem	Bezeichnung	Einhängepunkt

========================================
Primäre Partition Nr. 1 (xfs, 9.10 TiB) auf /dev/sde erstellen  11:34:49    ( FEHLER )
     	
Leere Partition erstellen  00:00:32    ( ERFOLG )
     	
Pfad: /dev/sde1 (Partition)
Anfang: 2048
Ende: 19532871679
Größe: 19532869632 (9.10 TiB)
Alte Dateisystem-Signaturen auf /dev/sde1 löschen  00:01:01    ( ERFOLG )
     	
write 512.00 KiB of zeros at byte offset 0  00:00:00    ( ERFOLG )
write 4.00 KiB of zeros at byte offset 67108864  00:00:00    ( ERFOLG )
write 4.00 KiB of zeros at byte offset 274877906944  00:00:00    ( ERFOLG )
write 512.00 KiB of zeros at byte offset 10000828727296  00:00:00    ( ERFOLG )
write 4.00 KiB of zeros at byte offset 10000829186048  00:00:00    ( ERFOLG )
write 8.00 KiB of zeros at byte offset 10000829243392  00:00:00    ( ERFOLG )
Zwischenspeicher des Betriebssystems /dev/sde leeren  00:00:00    ( ERFOLG )
Partitionstyp auf /dev/sde1 festlegen  00:01:03    ( ERFOLG )
     	
Neue Partitionstyp: xfs
Neues xfs-Dateisystem erzeugen  11:32:13    ( FEHLER )
     	
mkfs.xfs -f -L '' '/dev/sde1'  11:32:13    ( FEHLER )
     	
meta-data=/dev/sde1 isize=512 agcount=10, agsize=268435455 blks
= sectsz=4096 attr=2, projid32bit=1
= crc=1 finobt=1, sparse=1, rmapbt=0
= reflink=1 bigtime=0 inobtcount=0
data = bsize=4096 blocks=2441608704, imaxpct=5
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0, ftype=1
log =Internes Protokoll bsize=4096 blocks=521728, version=2
= sectsz=4096 sunit=1 blks, lazy-count=1
realtime =keine extsz=4096 blocks=0, rtextents=0
mkfs.xfs: libxfs_device_zero schreiben fehlgeschlagen: Eingabe-/Ausgabefehler

Daraus werde ich nicht wirklich schlau.

Da zur Zeit kein anderes "interessantes" USB-C-Kabel zum Testen vorhanden ist, wurde das neue Original-Fantec-Kabel nun hinten am PC angeschlossen, vorher vorne, dh interne Kabelverbindung im Gehäuse nach vorne.

Danach wurde ein bisschen rumprobiert.

parted /dev/sde -s -a optimal mklabel gpt mkpart primary 1 100%

war sofort erledigt.

time mkfs.ext4 -v -L "TESTING" /dev/sde1
mke2fs 1.46.5 (30-Dec-2021)
Dateisystemtypen für das Aufschlüsseln von mke2fs.conf: 'ext4', 'big'
Dateisystem-Label=TESTING
OS-Typ: Linux
Blockgröße=4096 (log=2)
Fragmentgröße=4096 (log=2)
Stride=0 Blöcke, Stripebreite=0 Blöcke
305201152 Inodes, 2441608704 Blöcke
122080435 Blöcke (5.00%) reserviert für den Superuser
Erster Datenblock=0
Maximale Dateisystem-Blöcke=4294967296
74512 Blockgruppen
32768 Blöcke pro Gruppe, 32768 Fragmente pro Gruppe
4096 Inodes pro Gruppe
UUID des Dateisystems: cb2e12ee-9818-4b4a-851d-e11560a59729
Superblock-Sicherungskopien gespeichert in den Blöcken: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000, 214990848, 512000000, 550731776, 644972544, 1934917632

beim Anfordern von Speicher für die Gruppentabellen: erledigt                            
Inode-Tabellen werden geschrieben: erledigt                            
Das Journal (262144 Blöcke) wird angelegt: fertig
Die Superblöcke und die Informationen über die Dateisystemnutzung werden
geschrieben: erledigt   


real	0m18,070s
user	0m0,083s
sys	0m0,351s

Also 18sec und nicht viele Stunden wie mit güarted.

Danach haben sich die "Command_Timeout" Werte nicht erhöht!

Innerhalb von ca. 10min. wurde Luks konfiguriert und komplett von vorne begonnen, also kurz badblocks, nach ein paar Minuten abgebrochen, parted und danach cryptsetup.

Jetzt läuft eine Sicherung, ich schätze mal die 10TB HD wird mit über 5TB gefüllt, eher mehr. Mal schauen, was dann smartctl meint.

Es könnte auch ein Problem der nicht aktuellen HDD-Firmware sein, aber da gibt es auch myteriöse Dinge. Die Part-No, die auf der HD aufgedruckt ist, gibt es in der Seagate FW-Liste nicht. https://forum.ubuntuusers.de/topic/firmware-von-seagate-hdd-unter-jammy-aktualisi/gl. https://forum.ubuntuusers.de/topic/firmware-von-seagate-hdd-unter-jammy-aktualisi/ Da geht es näherungsweise ST10000NM017B 2TL103-004, wir haben ST10000NM017B 2TL103-003.

Hallo glaskugel, wenn sich so eine Steigerung ergibt, dann liegt das sehr häufig am verwendeten USB-Kontroller im ext.Gehäuse. Der arbeitet dann eben nicht so toll mit dem USB vom Rechner zusammen.

Vorschlag:

Zum Test ein anderes ext.Gehäuse verwenden. Kein USB3.x nutzen, sondern auf USB2 verbleiben.

Es dürften hier "zeitliche Probleme", Übertragungsraten und Kontroller-Gags zusammen kommen.

Mit GPARTED wird ja ein enormer Befehlscode an die Kiste gesendet und man erwartet, dass das auch korrekt bearbeitet wird. Passiert schon irgendwie, nur nicht in der erforderlichen Geschwindigkeit.

Tipp:

Das Gerät an einen USB2 hängen und dort mit GPARTED einrichten lassen. Wenn alles passt, dann umstecken und versuchen zu arbeiten.

Tja, Technik ist schon was "feines".

BYE HS

Danke, steht auf der Todo-Liste.

Haha, 10TB mit USB-2.

Ich habe mir gedacht, die 10TB-HD temporär in den PC verbauen bzw. eine interne abstecken. Ist natürlich alles nicht so einfach für meinen Freund, der kein Spezialist ist.

Vielleicht ist auch das USB-Kabel grundsätzlich zu lang, es geht ja zuerst intern vom Mobo nach vorne und dann kommt die "Verlängerung" mit der vom Midi-Tower zum externen Gehäuse verbunden wird. Ich schließe grundsätzlich für größere Sachen hinten an, aber bei meinem Freund ist der PC unter dem Tisch "verbaut", da muss man alles rausschieben um zu den Ports zu gelangen.

Jetzt bin ich mal auf die neuen Samrt-Werte gespannt. Kriege ich vermutlich am Abend

Hallo glaskugel, würde ich so machen…

USB2… partitionieren… ein Backup 200GB hin und zurück… prüfen was läuft… entscheiden.

USB3 zu USB3.2 usw. hat schon enorme Unterschiede… macht so ein Kontroller eine "Denkpause" dann ist es ebenso… das Laufwerk wenn gerade in dem Moment eine Kurzanalyse macht ebenso… sind dann meistens Time-Outs…

Solche Denkpausen finden sich auch bei LAN-Verbindungen… einfach eine Woche laufen lassen beim Kunden und dann im programmierbaren/verwalteten Switch prüfen, welche Maschine "schläft" oder "übereifrig" ist. Erst wenn es sinnvoll zusammenpasst stellen wir dann die preiswerten Switche hin.

Noch spannender wird es, wenn es mehr als 2.5GB sind wird es spannend.

BYE HS

Ich weiß mittlerweile folgendes:

Auf die externe HD wurde nach der neuen Partitionierung nicht ganz 4TB geschrieben. Danach waren die Timwouts nicht erhöht. Alle anderen Smart-Werte sind auch ok, weniger als 8 Stellen.

Mein Bauchgefühl geht Richtung USB-Port bzw. dem internen Kabel nach vorne. Morgen sollte ein anderes USB-C Kabel kommen.

Ich lasse mir in den nächsten Tagen die externe HD vorbeibringen und schaue mir an, wie das mit dem FW flashen aussieht. Ich gehe davon aus, dass die richtige FW über die Serien-Nr. runtergeladen wird, auch wenn die Seagate-Tabelle die HD nicht listet.

Dann alles von vorne und wieder Backup und die Timeouts vergleichen. Wenn es passt, dann lassen wir es gut sein. Dann kommt die nächst HD daran.