externe USB Platte und das Herz bleibt stehen

Dilbert

Dilbert

Well-Known Member
Moin,

nachdem mein kleiner Testserver ja schon recht gut läuft ging es an das Thema Datensicherung. Diese wird bei mir auf eine externe Festplatte geschrieben.

Vorgehensweise:
Festplatte eingerichtet, Slice erstellt, Partition eingerichtet, Filesystem (UFS) und schön eingebunden.
Und nun schön mit rsync (kleines Script) die Datensicherung angeschoben.
Was ich bei der ganzen Sache übersehen hatte war das die externe Festplatte nicht mehr so ganz frisch war.
Lange Rede kurzer Sinn die Platte ist abgeraucht und hat das ganze System zum Stillstand gebracht.
Es ging wirklich nichts mehr, normalerweise bin ich nur über ssh am tun, ging nicht, weder die bestehende noch eine neue Verbindung. Also ab an die Tastatur (ist zum Glück noch dran). Wieder nichts.
Also ausschalten und mit dem ganzen Fehlermeldungsgeraffel wieder Starten.

Und da heißt es dann der USB Stack ist in 8.1 o.k. oder war ich das irgendwie der mal wieder nen Denkfehler hatte.

Das soll jetzt keine System schelte sein sonder eher die Frage nach dem warum, ansonsten bin ich nämlich sehr zufrieden mit den Möglichkeiten und der Freiheit das zu tun was ich möchte und nicht was sie der Distributor so ausgedacht hat.

Schönen Tag noch (es ist bald Wochenende :)
 
Hallo Dilbert,

mit USB Platten hatte ich leider schon viele schlechte Erfahrungen. Ein Rechner mit ASUS Mainboard unter FreeBSD 8.0 Release hat es partout nicht auf die Reihe bekommen eine Image Datei per DD auf den Stick zu übertragen, Aussetzer, Abbrüche, korrupte Ergebnisse. Die Hardware an sich war in Ordnung, mit Knoppix liefen alle Tests ohne Fehler durch.

Ansonsten hatte ich mal den Effekt bei einer 2 1/2" Platte dass sie (nachdem sie vorher 2 Jahre so lief) auf einmal trotz Y-Verteiler so viel Strom gezogen hat dass es zu einem ein-aus Rhythmus kam, erst ein unterstützendes externes Netzteil hat geholfen.

Ansonsten läuft USB eigentlich recht ordentlich, habe einige Systeme unter PC-BSD im Bekanntenkreis wo die Leute fröhlich ihre USB Sticks dranklemmen und fleissig Dateien hin- und herkopieren und auch die Datensicherung meines Servers auf USB funktioniert. Allerdings hatte ich dort auch mit dem Onboard Controller Probleme (nforce 4 Chipsatz) und musste eine separate USB Karte mit NEC Chipsatz einbauen.

Mit Deiner "abgerauchten" Platte, probier mal sie aus dem USB Gehäuse rauszunehmen und normal per SATA anzusteuern und gründlich zu testen, SMART Werte auslesen, Stresstests, etc... Würde mich nicht wundern wenn sie eigentlich OK ist.

Gruß
Shakky
 
Ja, warum? Das Meiste sagt shakky4711 über mir schon. Um es klar zu sagen, USB ist Schrott. Broken by Design. Basta und aus. Ich bin inzwischen so weit, unabhängig vom Betriebssystem USB-Speichermedien wann und wo es geht zu vermeiden, erst recht für kritische Dinge wie Backups. Stabilitätsprobleme mit USB kenne ich ebenfalls von jedem Betriebssystem, sie liegen nur jeweils an anderen Stellen. Unter dem Strich ist FreeBSD spätestens seit 8.0 in der Gesamtheit der Defekte nicht mehr besser und schlechter als die Konkurrenz.

Aber etwas ausführlicher. USB wurde Mitte der 90er von Intel eingeführt um diverse Alt-Schittstellen für Pheripherie abzulösen. Dabei dachte man vor allem an Tastaturen, Mäuse, Drucker, mit ein wenig Wohlwollen vielleicht auch noch Scanner. All diese Geräte haben eines Gemeinsam, es sind im Wesentlichen "Fire and Forget"-Geräte. D.h. man schickt Daten und ob sie auf der anderen Seite wirklich fehlerfrei ankommen, kann einem relativ egal sein. Außerdem sind diese Geräte meist billig und haben selbst nur wenig Logik eingebaut. Man traf daher zwei grundlegende, bis heute gültige Designentscheidungen:

a) USB ist ein weitgehend auf Polling basierendes System. Während die Konkurrenz in Form von ATA, S-ATA, Firewire, SCSI, SAS und diversen mehr auf Interrupts basiert, tut USB es nicht. Bei anderen Techniken sagt das Gerät simpel gesagt dem Computer "Ich habe Arbeit für dich". Bei USB ist es umgekehrt, der Computer fragt "Hast du Arbeit für mich?". Er muss diese Frage immer und immer wieder stellen, um nichts zu verpassen. Für Tastaturen und co, die ein sehr geringes Datenaufkommen haben, ist das okay und halt billig zu bauen. Für höhere Geräte, von denen es inzwischen eine Myriade gibt, ist das "Pain in the Ass" oder kurz PITA. Polling ist langsam. Sieht man am bescheidenen Datendurchsatz bei Platten, ich habe noch nie eine USB-Platte gesehen, die die theoretisch möglichen 60MB/s von USB 2 auch nur annähernd erreicht. Polling bring Timing-Probleme mit sich. Sieht man an den USB<->RS232-Konvertern. Vor allem aber ist Polling sehr schwer effizient zu programmieren, gerade wenn man noch Strom sparen möchte.

b) Tastaturen und co. brauchen keine Fehlerkorrektur. Es ist egal, ob da mal ein Bit kippt. Die Schaltungen kosten mehr Geld, als eine manuelle Korrektur. USB hat daher eine absolut bescheidene Fehlerkorrektur. Das bedeutet nichts anderes, als dass das System in weiten Teilen auf Gott vertraut und betet, dass doch bitte keine Bits kippen. Für Speichermedien ist das sehr bescheiden, weil bei den langen Kabeln, den billigen Controllern und relativ großen Datenmengen die Fehlerrate hoch ist. Ich konnte in Tests bei mehreren Terrabyte Daten unter allen Betriebssystemen gekippte Bits feststellen. Bei Filmen und Musik mag das egal sein, aber bei Programmen und Textdokumenten kann das schnell zur Katastrophe führen.

Dazu kommt der allgemein sehr hohe Schrottfaktor bei USB. Wirklich hochwertige USB-Hardware gibt es leider kaum. Das Meiste ist standardinkonform, defekt ab Werk und vieles negatives mehr. Auf Controllerseite hat sich das relativiert. Sowohl AMD als auch Intel hatten in den letzten Generationen eigentlich recht brauchbaren Krams verbastelt, solange die Firmware denn stimmt. Mit nVidia hingegen habe ich es niemals geschafft, unabhängig vom Betriebssystem eine nach meinen hohen Ansprüchen saubere Funktion hinzubekommen. Aber auf Gerätseite ist die Katastrophe groß wie eh und je.

Daher mein eindringlicher Rat. Egal ob man nun Windows, OS X, Linux, FreeBSD oder sonst was benutzt. Man tut gut daran kritische Daten - wie z.B. Backups - nicht über USB zu machen. Firewire und E-SATA sind von den bezahlbaren Schnittstellen wesentlich robuster und geeigneter. Außerdem im Durchsatz weitaus schneller. :)

Dennoch. Wenn die Platte nach einiger Zeit zu spinnen beginnt, wenn sie am Ende sogar das System crasht, ist das ganz klar ein Bug. Zumindest crashen darf er nicht. Ich würde dich daher bitten, einen Bugreport zu schreiben oder dich an freebsd-usb@ zu wenden. Die Jungs da sind sehr hilfsbereit und unter dem Strich sicher die Einzigen, die dir wirklich helfen können.

EDIT: Nur als Anmerkung, USB 3 ist von Grund auf neu designed und basiert auf PCI Express. Es hat die oben genannten Probleme in weiten Teilen nicht mehr. Es gibt für FreeBSD bereits einen Patch, der Unterstützung einfügt...
 
Also ich hab einen ganzen Haufen USB2.0 Festplatten noch an nem 7.2 Server hängen und der werde Gigabyte-weise Daten druafgeschaufelt.
Noch nie Probleme gehabt.
Backups verrichten bei zig Kunden ebenfalls auf die USB Platten einwandfrei den Betrieb. Ich kann das von der Praxis her nicht bestätigen. :)


EDIT: Alles Intel Controller.
 
Erst mal Danke für die Info, ist ja eine sehr schöne Mischung.
Hatte und hab bis dato (auf Debian Systemen) keine Probleme mit USB Platten. Die Infos von Yamagi geben einem zumindest zu denken. Da ich den Systemabsturz ungern wiederholen möchte (ist vielleicht auch nicht reproduzierbar) werde ich wohl kaum einen Bugreport zustande bringen.

Aber eine neue USB Festplatte die lag noch hier rum (diesmal mit y-Kabel angeschlossen), alles wieder auf Anfang und siehe da rsync ist ohne Fehler (zumindest was leicht zu sehen ist (gekippte Bits sind es für mich erst mal nicht)) durchgelaufen. Soweit so gut. Die andere Platte werd ich die Tage mal prüfen um einfach zu sehen wo es hängt.

Noch zur Info, es handelt sich bei dem Server um ein noch nicht ganz durch getestetes VIA EDEN System (im Volllastbetrieb ca. 30Watt mit einer 2 1/2" 24/7 SATA Platte).
Hab bei einem anderen Projekt mit dieser / ähnlicher Hardware (Dauerbetrieb seit ca. 4 1/2 Jahren) sehr gute Erfahrungen gemacht.

Soweit so gut, wenns noch was neues gibt meld ich mich wieder
 
ich weiß nicht, ob du das auch gemacht hast, aber es ist jedenfalls in solch einem Fall sehr empfehlenswert (nach meiner bescheidenen Erfahrung), die Platte durch das Script nur für die Zeit der Datenübertragung gemountet zu lassen und hernach wieder zu umounten.
Dabei habe ich auch gerne eine bestimmte Datei auf dem Medium angelegt, die nur dem Zweck diente, dieses zu identifizieren und also Zweifelsfrei sicher zu stellen, dass die richtige Platte eingebunden ist und dass sie eben auch tatsächlich eingebunden ist, bevor der Datentransfer anläuft.
Dadurch wird die Handhabung von USB-Platten meiner Ansicht nach etwas unkritischer und außerhalb der Sicherungszeit können diese auch einfach mal entnommen werden.

dd unter FreeBSD ist für mich unabhängig von USB so eine Sache. sdd (sysutils/sdd) mag ich ein wenig mehr. sdd unter FreeBSD ist ähnlicher (für meine Anwendungsfälle) zu dd unter Linux. Vielleicht haben die dort sogar sdd benutzt, um ihr dd zu bauen. Jedenfalls habe ich weniger Probleme, seit ich sdd benutze.
 
Moin,

nach dem "Absturz":

nachdem ich unter der bestehenden ssh Verbindung auch nach ctrl-c keine Möglichkeit mehr hatte hab ichs mit einer neuen ssh Verbindung versucht. Kein Zugriff. Über lokale Taststur ging auch keine Anmeldung mehr. Platte abgezogen (mindestens gefühlte 30 min. gewartet), nichts ging mehr . Da hat nur noch ein Reset geholfen.

Das Log gibt folgende Fehlermeldung aus (und zwar ne Menge davon):

Aug 31 17:08:08 server kernel: g_vfs_done():da0s1a[WRITE(offset=18937282560, len
gth=16384)]error = 5

@pit234a

Ablauf vom Script (wird normalerweise über cron gestartet)

Festplatte mit sdparm starten (die muss ja nicht den ganzen Tag rumdrehen)
Platte mounten
Datensicherung durchführen
Umount der Platte
Platte mit sdparm stoppen

Das wars.

Bin noch nicht dazu gekommen die Platte an einem anderen System zu prüfen. Kommt aber noch ne Rückmeldung.
 
Ich habe genau das gleiche Phänomen mit einer USB-Platte/Wechselgehäuse. Ich will eigentlich mein System mittels dump/restore von einer 60GB auf eine 250GB Platte migrieren.
/root /tmp und /var klappten auch problemlos, nur bei der knapp 200GB großen /usr Partition flog mir das System relativ schnell um die Ohren.
Die Fehlermeldungen sind identisch.

Ich hatte ursprünglich den Fehler auf dump geschoben, aber cpdup z.B. funktionierte auch nicht besser.

Eigentlich müsste ich nur einmal /usr kopieren, danach kann mir USB gestohlen bleiben. ;)
 
Bin ja noch ne Antwort schuldig.
Platte an einem anderen System geprüft, jetzt mit ext3 und sie läuft.
Hab hin und her kopiert, alles lief einwandfrei.
Gleiches System nur mit einem anderen Betriebssystem Debian Lenny (andere Platte eingebaut) und wieder läuft alles. Hardwarefehler kann ich wohl ausschließen.

Schieben wir das ganze mal auf die Infos von Yamagi und auf die Hard- / Software Kombination
 
Dilbert schrieb:
Bin ja noch ne Antwort schuldig.
Platte an einem anderen System geprüft, jetzt mit ext3 und sie läuft.
Hab hin und her kopiert, alles lief einwandfrei.
Gleiches System nur mit einem anderen Betriebssystem Debian Lenny (andere Platte eingebaut) und wieder läuft alles. Hardwarefehler kann ich wohl ausschließen.

Schieben wir das ganze mal auf die Infos von Yamagi und auf die Hard- / Software Kombination
Zum Vergrößern anklicken....
Du hast unter Debian auch auf die Platte im USB-Gehäuse kopiert?
Gleiche Hardware?

Ich habe schon eine Linux-Rescue-CD zum Kopieren in Erwägung gezogen, leider konnte die mit dem FreeBSD Format nix anfangen.
Es muss doch möglich sein die Partitionen zu migrieren, ohne das ganze System neu installieren zu müssen ... :(
 
oenone schrieb:
Ich dachte, die Quellplatte wäre 60GB? Wie äußert sich das "um die Ohren fliegen"?
Zum Vergrößern anklicken....

Stimmt, die Quellplatte ist bloss 60GB groß. Aber die /usr Partition soll von der 45GB Partition auf eine 200GB Partition migriert werden. /root und /var habe ich auch erfolgreich auf etwas größere Partitionen schieben können.
Nur bei /usr kommt es zu Fehlern:

Code: 
Sep 28 20:48:28 hogwarts kernel: (da0:umass-sim0:0:0:0): AutoSense failed
Sep 28 20:48:28 hogwarts kernel: g_vfs_done():da0s1f[WRITE(offset=90163247104, l
ength=2048)]error = 5
Sep 28 20:48:28 hogwarts kernel: g_vfs_done():da0s1f[WRITE(offset=90163253248, length=2048)]error = 5
Sep 28 20:48:28 hogwarts kernel: g_vfs_done():da0s1f[WRITE(offset=90163265536, length=2048)]error = 5

[...]

Das zieht sich dann hin bis zum automatischen Reboot (ohne X, wenn X läuft bleibt der Laptop einfach irgendwann stehen und reagiert nicht mehr).
 
Da ist das Gerät abgestützt. Das an sich ist ärgerlich, der eigentliche Bug liegt aber darin, dass der Kernel anscheinend ebenfalls in die Knie geht. Du solltest einen Bugreport aka PR schreiben. :)
 
Yamagi schrieb:
Da ist das Gerät abgestützt. Das an sich ist ärgerlich, der eigentliche Bug liegt aber darin, dass der Kernel anscheinend ebenfalls in die Knie geht. Du solltest einen Bugreport aka PR schreiben. :)
Zum Vergrößern anklicken....

Ich werde es heute Abend noch einmal probieren. Ich hatte zu dem Zeitpunkt noch 8.1-RELEASE und inzwischen auf 8.1-STABLE aktualisiert. Außerdem wird sämtlicher USB-Support nun als Modul geladen (ich bastel immer noch an einer Möglichkeit mein Laptop einschlafen zu lassen und wieder aufwecken zu können...).

Vielleicht hat sich dadurch das Verhalten gebessert/geändert. Wenn nicht, schreibe ich gerne mal einen Bugreport. Gibt es da eine Howto dazu? (Auf meinem stationären PC hatte ich nie Probleme mit irgend welcher Hardware/Treibern...)
 
oenone schrieb:
Sieht aus, als wäre da was mit USB gestorben...
Zum Vergrößern anklicken....

Evtl. liegt es auch einfach an dem brackigen USB-SATA-Gehäuse. Das habe ich mir von einem Arbeitskollegen geliehen, da ich selbst selten eins brauche. [1] Der Anschaffungspreis lag wohl bei knapp 5 Euro, was mir sehr billig scheint. ;)

[1] Den Umzug von der 250GB Platte auf eine 500GB Platte unter OS X hat es allerdings noch ganz gut mitgemacht.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben