Tobi’s Blog

Gedanken zur Softwareentwicklung und anderes

Backups, Teil 2: Ursachen für DVD-Probleme und Test der DVD-/CD-Fehlerkorrektur

Erstellt von Tobi am Freitag 29. Mai 2009

Wegen meiner Datenverluste hab mich mal im Netz und im Handel schlau gemacht, ob es ggf. Rohlinge gibt, die haltbarer bzw. besser geeignet sind. O-Ton: eigentlich nicht. Auf einen Hersteller kann man sich wohl nicht mehr verlassen, da alle in Fernost bei Billiganbietern produzieren und man quasi jeden Monat von der gleichen Marke Rohlinge eines anderen Herstellers bekommen kann. Außerdem ist generell die Datenschicht von DVD-ROMs, wohl aus Kostengründen, aus wenig haltbaren, organischen Materialien hergestellt. Diese sind sehr anfällig gegen Licht und jede andere Alterungserscheinung.

DVD-RW dagegen bestehen aus anorganischem Material, ebenso wie DVD-RAMs. Bei letzteren hörte ich nur Gutes von der Haltbarkeit, musste aber feststellen, dass das ein absolut unbrauchbares Format ist. Kein mir bekanntes DVD-Laufwerk unterstützt die Dinger und zum Kauf hab ich auch noch keine gesehen. DVD-RWs dagegen sind zwar etwas teurer als DVD-ROMs, aber mit ca. 1 € pro Rohling könnte ich gut leben, wenn es denn hält.

Ein weiterer Punkt für die Anfälligkeit aller DVD-Arten der öfter genannt wurde ist, mit Ausnahme bei der DVD-RAM, die offenbar schlecht umgesetzte “Fehlerkorrektur”. Es werden bai allen dieser Datenträger redundante Daten “intelligent” auf der Oberfläche verteilt und zwar so, dass übliche Fehler wie Kratzer, ausgeglichen werden können. Es gibt aber bei der DVD das Problem, dass die inneren und die äußeren Bereiche damit nicht ordentlich abgedeckt werden und somit besonders gefährdet sind. Beim Innenbereich ist das besonders kritisch, denn wenn der unlesbar ist, erkennt das Laufwerk den Datenträger nicht mehr als solchen und man kann gar nichts mehr machen. Für diesen Fall gibt es zwar auch Programme im Netz, aber die haben bei mir keinen Erfolg gebracht.

Der Kratztest

Alleine die Aussagen der Händler oder die Infos im Netz helfen mir wenig. Praxiserfahrung musste her. Also ging ich im ersten Schritt daran, verschiedene Rohlinge voll zu schreiben und Kratzer in verschiedener Formen und an verschiedenen Stellen zu machen und die Auswirkungen zu untersuchen. Da das Programm dvddisaster auch eine Checksummendatei zur besseren Fehlerkorrektur anbietet und ich ja dann schon defekte Datenträger hatte, konnte ich das auch gleich mit testen.

Zur Vorbereitung hab ich eine DVD und eine CD voll beschrieben und das ISO-Image der beiden auf die Platte gesichert. Von diesen Images hab ich mit dvddisaster zwei Checksummendatei (ECC) mit den Standardvorgaben des Programmes erstellt. Eine “normal” mit 14,2% und eine “hoch” mit 33,5% Redundanz. Nebenbei: selbst wenn diese Dateien gut sind, haben sie doch das Problem, dass man auch sie irgendwo sichern muss. Sinniger weise nicht auf der gleichen und eigentlich auch auf keiner anderen DVD, aber wo dann?

Nachdem ich auf die Art vom gleichen Image einige DVDs und CDs gebrannt hatte, fing ich an, mit einer Schere Kratzer auf die Unterseite zu machen. Die extreme dabei hab ich mal notiert

Fehlerverhalten bei Kratzern auf DVDs

Alle Typen verhalen sich gleich: +RW, -RW, +R, -R

4 Kratzer von der Mitte bis zum Außenrand
dvd-kratzer-3
Kein Schaden. Das kann die Fehlerkorrektur gut ab, scheinbar ist sie genau dafür da.
Ein 2cm Kratzer, fast mit der Spur
dvd-kratzer-1 4500 x 5 Sektoren kaputt. Das sind bei 2KB Sektorgröße 45MB, aber im Zweifel schon ein riesen Problem. Mit der normalen Checksummendatei ist es komplett restaurierbar. Anmerkung: auf dem Bild ist noch ein Kratzer zu sehen, den hatte ich später drau gemacht und weiter getestet. Der hatte keine weitere Auswirkung mehr.
6 Kratzer, davon 4 mit der Spur
dvd-kratzer-4
Die hälfte der Daten ist Defekt. Die hohe Checksummendatei hilft genauso wenig weiter wie die normale. Damit lassen sich noch ein paar Prozent retten, mehr aber nicht.
3 mal 1cm Kratzer innen fast am Loch und fast mit der Spur
dvd-kratzer-2
Die DVD lässt sich nicht mehr lesen, d.h. das Laufwerk will sie nicht mehr haben. Dementsprechend ein Totalverlust. Mit ein bisschen Rumprobieren hab ich es auch mit einem einzigen, 1cm langen Kratzer hinbekommen. Die Archillesferse der DVD. Da darf nix schief gehen.

Ich hab einige Rohlinge zerlegt und konnte immer nur wenige Kratzer hinterlassen, bevor nicht über 50% der Daten drauf gingen. Gab es einen kratzer in der mitte wurde die DVD oft nicht mehr als solche erkannt. Die Checksummendateien von DVDdisaster helfen bei kleinen Fehlern, aber ansonsten sind sie eher was zum Gewissen beruhigen als eine echte Hilfestellung.

Fehlerverhalten bei Kratzern auf CDs

Hier war ich ziemlich erstaunt. Ich fing vorsichtig an und mit jedem Kratzer gab es Fehler. Egal ob mit oder quer zur Spur. Die Fehler ließen sich mit den Checksummendateien nur ganz am Anfang nurtzbringend verwenden. Ab 4 Kratzern war es dann egal und es gab Datenverluste. Interessant fand ich nur, dass ich den Datenträger nicht zerstören konnte. Ich hinterließ 38 tiefe Kratzer mit bis 5cm länge, mit und quer zur Spur cd-kratzer-1. Auch so verteilt, dass sowohl ganz innen und ganz außen mit der Spur einiges zerkratzt war. Danach hatte ich weder Lust noch Kraft und außerdem irgendwie keinen Platz mehr auf der Oberfläche um noch was beschädigen zu können. Die CD war zu 95% nicht mehr lesbar, wurde aber noch korrekt als CD erkannt.

Fazit aus dem Kratzertest

DVDs sind gerade ganz innen tatsächlich extrem empfindlich. Fehler von innen nach außen sind gut abgefangen aber solche mit der Spur sind ein riesen Problem. Bei CDs sind Fehler immer ein Problem, aber es gibt keine besonders empfindlichen Stellen. Diese Info nützt, ganz allein für sich, gar überhaupt nichts. Im Zusammenhang ist es aber entscheidend. Dazu mehr im dritten Teil.

Und noch Abschließend, obwohl ich es oben schon erwähnt hatte: die ECC-Checksummendateien von dvddisaster sind wenig hilfreich. Eine sinnvolle Speicherlösung bringt da mehr.

Demnächst dann Teil 3 mit dem Langzeittest der Alterung von DVD-ROM, DVD-RW und CD und dem abschließenden Fazit.

Abgelegt unter Technik | 1 Kommentar »

Backups, Teil 1: Datenverlust bei DVDs und Rettungsmöglichkeiten

Erstellt von Tobi am Mittwoch 27. Mai 2009

Vor einigen Jahren, so ungefähr als CD-ROM’s aufkamen, begann ich meine Daten auf die Silberschreiben als Backup zu brennen. Schon damals vertraute ich den Dingern wenig und legte immer gleich 2 gleiche an. Mit den Jahren verflog die Angst vor Datenverlust, weil ich keinerlei Probleme selbst mit 10 Jährigen CD-Rohlingen hatte. Als dann DVD’s erschwinglich wurden, übernahm ich das Vertrauen in die neuen Datenträger und benutzte ab dann diese für meine Backups. Das war ein Fehler, den ich bitter bereuhe und auch teuer bezahlt habe.

Das Problem

Insgesamt hatte ich über 2 1/2 Jahre hinweg, meine Backups sporadisch auf DVD’s verteilt, wie es halt gerade passte. Insgesamt haben sich 15 DVDs auf die Art angesammelt, die ich vor einiger Zeit dann mal sortieren und sauber archivieren wollte. Allesamt, ok bis auf eine, in der Hülle im Schrank aufbewahrt und ohne Kratzer, Staub oder sonstige Gebrauchsspuren. Beim Auslesen erhielt ich folgendes, niederschmetterndes Ergebnis:

2 DVDs komplett unbrauchbar
Eine lag für ca. eine Woche auf meinem Schreibtisch (Nordseite des Hauses) und war komplett ausgeblichen, da kann ich den Schaden ggf. noch verstehen, wenn auch nicht wirklich. Die andere war von einfach so kaputt, ohne verkratzt oder ausgeblichen zu sein. Kein Laufwerk konnte sie noch als DVD erkennen. Ein Totalverlust.
4 DVDs schwer beschädigt
Nicht verblichen und keine Kratzer zu sehen. Die äußeren Sektoren waren komplett im Eimer und auch in der Mitte gabs gute Fehlerstellen (woher ich die Fehlerstellen so genau weiß gibts weiter unten). Insgesamt waren ein paar 100MB weg.
6 DVDs leicht beschädigt.
Wieder trotz einwandfreihem Zustand. Hier gabs nur vereinzelte Feher, meißt am Außenrand
2 DVDs minimal beschädigt
Wieder ein super Zustand. Wenn ich sie nur “normal” ausgelesen hätte z.B. über die Dateiverwaltung, währen auch hier Fehler wie bei den 6 leicht beschädigten aufgetreten. Aber mit meinem Lebensretter-Tool konnte ich wenigsten die Daten komplett retten

Damit bleibt, nach Adam Riese, genau EINE komplett unbeschädigte DVD übrig. Da ich das Datum des Brennvorganges auf die DVD gekritzelt hatte, kann ich sagen, es hat sehr viel, wenn nicht alles, mit dem Alter der DVDs zu tun. Der Rohling-Typ war uninteressant, denn Vertreten sind die Marken Fujifilm, Tevion, Intenso und Octron und keiner der Rohlingtypen wurde von Fehlern verschont.

Die (teilweise) Rettung

Geholfen hat mir in erster Linie die Tatsache, dass meine Backups so verteilt und völlig unorganisiert waren. Dadurch waren viele Daten redundant und ich konnte so ca. 90% retten. Aber 10% Verlust, gerade bei z.B. alten Fotos, sind zu hart. Für weitere ca. 9% half mir das Linux-Tool dvddisaster. Die Idee dahinter ist so einfach wie genial. Man kann eine DVD einlesen und jeder einzelne, korrekt gelesene Sektor wird einem ISO-image auf der Platte hinzugefügt. Man kann dann das Image auf einen anderen Rechner legen und mit dessen Laufwerk das ganze nochmal versuchen. Sind dort Sektoren lesbar, die bisher noch fehlten, wird das ISO-Image aufgefüllt. Auf die Art kommt man schon recht weit.

Außerdem kann man das Laufwerk noch so ansteuern, dass die eingebaute Fehlerkorrektur umgangen und diese Arbeit vom Programm übernommen wird. Auch das hilft enorm. Auf diese Art konnte ich die 2 minimal beschädigten DVDs komplett und fehlerfrei auslesen. Mit den Einstellungen, jeden Sektor 10 mal zu lesen und die Fehlerkorrektur auf jede erdenkliche Art zu versuchen, kann man wirklich was erreichen. Das erkauft man sich aber durch sehr viel Zeit, denn meine schlimmste DVD brauchte ganze 1 1/2 Tage um ausgelesen zu werden. Leider nicht komplett fehlerfrei.

Besonders gut an dem Programm ist, dass man aus zwei oder mehr fehlerhaften DVDs eine ganze machen kann, vorausgesetzt man hat exakt gleiche Kopien einer DVD und die Fehler liegen nicht an den selben Stellen. Aber ich dachte ja, zumindest damals, dass Redundanz dieser Art nicht mehr nötig sei.

Der Verlust

Auf den 2 komplett unbrauchbaren DVDs war nur ein TV-Mitschnitt eines Konzertes und ein “bisschen” Musik. Beides ist nicht toll, aber verschmerzbar. Es hätte mich schlimmer erwischen können. Ansonsten fehlt mir nur ein 20KB großes Stück eines tgz-Archives, was gesamt 150MB groß ist. Das sind alle Bilder von vor 2002 die ich besitze. Man könnte denken, dann ist halt nur ein, maximal noch ein Zweites Bild im Archiv kaputt. Aber auch da war mir das Glück nicht hold.

Probleme mit Archiven

TGZ Archive sind scheinbar extrem FehlerINtolerant, denn ich kann die 500kb VOR der fehlerhaften Stelle entpacken, alles dahinter liegende nicht. Ich habe noch keine Möglichkeit gefunden, das zu Umgehen, hoffe aber noch auf eine Rettunng. Auf der Suche nach brauchbaren Alternativen bin nur über Gerüchte gestolpert, das RAR da besser sei. Das werd ich aber auch noch mal genauer testen.

Weiteres Vorgehen

Den Grund für die Ausfälle wollte ja schon herausfinden, also musste Ursachenforschung betrieben werden. Außerdem eine neue Lösung für Backups.

Da das Tool einem auch anzeigt, wo genau die fehlerhaften Sektoren auf der Oberfläche zu finden sind, zumindest kann man sehen, ob es eher im Innenbereich oder eben weiter außen Fehler gab, erhält man einen guten Überblick über den Zustand der DVD. Durch die Anzeige, wie schnell welcher Teil ausgelesen werden konnte, sieht man auch bei komplett fehlerfreihen DVDs und CDs, wie es um den Datenträger steht, da das Laufwerk langsamer wird, je problematischer der Lesevorgang war. Das war eine gute Grundlage, mal ein paar Tests mit den löchrigen Scheiben zu machen.

Folgende Dinge habe ich bereits durchgeführt und werde die Tage ausführlicher darüber berichten:

  • Ursachenforschung, warum DVDs so Probleme machen und ob und wie man die umgehen kann
  • Test der Fehlerkorrektur bei DVD und CD bei Kratzern.
  • Qualität der Checksummen-Dateien zur Fehlerkorrektur mit dvddisaster
  • Langzeittest der Alterungserscheinungen von DVD-ROM, DVD-RW und CD

Fazit

Backups IMMER redundant anlegen und DVD-ROM keinesfalls vertrauen. Da kann man auch gleich seine Daten in /dev/null schieben. Auch Archive oder Verschlüsselung bei Backups nicht verwenden, da die das Problem nur vergrößern. Lieber mehr Datenträger benutzen und die dann wegschließen. Und Teil 2 lesen :)

Abgelegt unter Technik | 2 Kommentare »

Schreiboperationen auf SSD vermeiden (unter Ubuntu)

Erstellt von Tobi am Montag 25. Mai 2009

Wenn man schon so ‘nen Schicken EEE-PC 901 geschenkt bekommt, will man den ja auch richtig einrichten. In dem Ding ist z.B. eine SSD verbaut und da sich die Schreibzyklen stark auf die Lebensdauer auswirken, dachte ich mir, kann man da doch bestimmt was machen.

Geplant war, die Teile der Platte, die häufige Schreiboperationen erdulden müssen, irgendwie zu schützen und die Änderungen gesammelt auf die Platte zu schreiben. Genau nach diesem Prinzip funktioniert unionfs. Man kann beliebig viele Quellen der Reihe nach übereinander legen und die oberste Quelle mit Schreibrechten wird eben zum Schreiben aller Änderungen benutzt, die darunter liegenden Schichten nur zum Lesen. Im vorliegenden Fall habe ich also die Teile der Platte, die geschützt werden sollten, als unterste Schicht mit Schreibschutz verwendet und oben drüber eine RAM-Disk gelegt.

Orte mit vielen Schreiboperationen

Folgende Verzeichnisse konnte ich bei Ubuntu ausmachen, die oft geschrieben werden:

/tmp
Das allgemeine, temporäre Verzeichnis. Viele Scripte legen da ihren Kram ab, aber viel Platz verbraucht es nie.
/var/tmp
Noch ein temporäres Verzeichnis. Keine Ahnung, wer da so alles rein schreibt. Ebenfalls recht klein vom Platzbedarf.
/var/log
Alle Logdateien (eigentlich) aller Prozesse. Hier wird städig rein geschrieben und gerade Desktopanwender brauchen die Infos nie
/media
Ein leeres Verzeichnis, in dem beim mounten von z.B. USB-Sticks Verzeichnisse als Einhängpunkte erstellt und später wieder entfernt werden.
/home/*/
Das Benutzerverzeichnis des aktuell angemeldeten Benutzers wird bei laufender X-Oberfläche ständig beschrieben. Da ist, neben /var/log, so ziemlich am meisten los.
/etc/mtab
In dieser Datei wird jegliches Ein- und Aushängen von Datenträgern dokumentiert.

Bei so vielen zu schützenden Verzeichnissen bedeutet das am Ende aber, dass man viele RAM-Disks anlegen muss. Ich bin mir nicht sicher, aber die Dinger wachsen dynamisch mit bis zur angegebenen Obergrenze, wenn man Daten hinein legt. Entfernt man aber Daten, glaube ich nicht, dass der Speicher wieder freigegeben wird. Zumindest nicht alles und auch nicht sofort. Also sollte es, um dieser Frage einfach aus dem Weg zu gehen, nur eine RAM-Disk geben. Außerdem ist dann die Verwaltung des verbrauchten Platzes einfacher und die Überwachung, wie viel noch frei ist, ebenfalls.

SSD-FS als Init-Script

Um die Aufgabe möglichst einfach zu erledigen, hab ich dieses ssdfs-Script erstellt, dass zur Boot-Zeit direkt nach dem mounten aller normalen Laufwerke aus /etc/mtab eine RAM-Disk erstellt und an die entsprechenden Verzeichnisse per mount –bind hängt. Auch /etc/mtab wurde per –bind an eine Datei auf der RAM-Disk gebunden. Die Verzeichnisse, deren Daten erhalten bleiben sollen, wurden per unionfs und weiteren Teilen der RAM-Disk schreibgeschützt. Die Installationsanleitung sowie ein paar Kommentare zum Verhalten und ein paar Schalter zum Debuggen etc. sind im Script selbst ganz oben enthalten. Das Script würde ich aber als Entwicklerversion ansehen und keinesfalls für den Normalbetrieb benutzen. (siehe weiter unten)

Erfolge

Insgesamt konnte ich das Dateisystem damit so schützen, dass vom Einschalten des Rechners bis zum Ausschalten nur 45 Schreiboperationen ausgeführt wurden. Und die alle in /etc/mtab (mehr dazu gleich, unter “Probleme”). Alle Änderungen an den Daten werden beim Runterfahren am Stück geschrieben und so unnötiges Schreiben verhindert.

(Schwere) Probleme

Folgende Probleme sind mir beim Entwickeln aufgefallen, die leider so gravierend sind, dass ich das Projekt erst mal verworfen habe:

Unionfs kann kein Merge
Mit unionfs kann man auf simple Weise die ursprünglichen Daten und Änderungen trennen. Das wird z.B. bei Live-CDs benutzt, um das System normal zu benutzen ohne auf die CD-ROM schreiben zu können. Aber es wurde nur GENAU DAFÜR gemacht. D.h. man kann nicht sagen “führe die Änderungen jetzt mal auf die ursprünglichen Daten aus”. Im Script habe ich einen Trick benutzt, das selber zu machen: es wird per rdiff einfach eine Daten mit allen Änderungen zwischen den ursprünglichen Daten und dem kompletten Unionfs durchgeführt. Das dauert zwar etwas länger, da alle Daten ein mal gelesen werden müssen, funktioniert aber zuverlässig.
Unionfs ist zickig
Wenn man unterhalb eines Unionfs per –bind Verzeichnisse eingehangen hat, bleibt ein umount des Unionfs einfach stehen. Man kann dann nur noch hart ausschalten und alle Daten, die noch nicht auf die Platte gesynct wurden, sind verloren. Auch kann man Unionfs-Quellen nur aushängen, nicht den Status ändern oder sie gar wieder einhängen. Das führt ebenfalls zum Absturz des Unionfs und eben wieder zum Datenverlust. Daraus ergibt sich, dass man ein Sync der Daten auf die Platte nur genau ein mal machen kann. Ein regelmäßiges Syncen, um Datenverluste zu vermeiden durch ausgehen des Rechners z.B. durch zu wenig Akkuleistung, ist nicht möglich.
/etc/mtab wird uneinheitlich verwendet
Hier waren, nach dem alles andere recht gut lief, die letzten 45 Schreiboperationen zu finden. In dem Init-Script der mtab ist extra angegeben, wenn die Datei ein Link ist, dass dieser dann korrekt behandelt wird. Das funktioniert aber gar nicht, da andere Prozesse diese Ausnahme nicht kennen und das System schon beim Starten korrumpieren. D.h. die unionfs-Laufwerke werden zwar erstellt, können aber nicht mehr gesynct werden und es gehen somit wieder Daten verloren. Per mount –bind kann man auch einzelne Dateien binden, aber auch das funktioniert hier nicht. Der df-Befehl z.B. erkennt dann überhaupt kein Laufwerk mehr, und unionfs lässt nicht schon wieder nicht unmounten… und wieder mal Datenverlust.
Umount von per –bind eingebundenen Laufwerken ist zickig
Wegen der Zickigkeit von Unionfs habe ich mehrere Laufwerke übereinander legen müssen, um z.B. das Unionfs beim Syncen mit einem Schreibschutz versehen zu können, da Unionfs bei dieser Aktion direkt abstürzt und wenn beim Syncen gleichzeitg Änderungen in der Quelle gemacht werden, bestimmt viel Datenmüll raus kommt. Bei so verschachtelten –bind Anweisungen scheint es umount irgendwann aus der Bahn zu werfen. Sporadisch wurde ein Umount verweigert, was wieder zu Datenverlust führte.

Fazit

Dieser Weg funktioniert ziemlich gut, ist aber extrem Instabil und führt zu gravierenden Datenverlusten. Zum basteln und lernen ist das gut geeignet, zu mehr aber auch nicht. Zum Vergleich: Ich habe während der Entwicklung das System ca. 200 mal neu starten müssen und ~90% der Zeit die Daten der Sitzung komplett verloren.

Ich für meinen Teil habe viel über Unionfs, die mtab und das System an sich gelernt. Das Script selber werde ich aber erst dann wieder anfassen, wenn Unionfs “etwas” stabiler geworden ist. Ansonsten richte ich mir die Umgebung gerade so ein, dass die Daten, die oft geschrieben werden, auf einer SD-Karte liegen und nicht auf der SSD, um bei Ausfällen für 10 € einfach eine neue SD-Karte zu kaufen statt einer teuren SDD. Aber dazu später mehr

PS:

Ich hab den Blog schon gute 3 Monate komplett vernachlässigt, was aber meinem Garten zuzuschreiben ist, denn im Frühling ist da einfach sehr viel zu tun. Jetzt, wo ich quasi nur auf’s Ernten warte, werd ich auch wieder mehr schreiben.

Abgelegt unter Linux(Ubuntu) | Keine Kommentare »

Falschens Rückenleiden beim Hund

Erstellt von Tobi am Samstag 2. Mai 2009

Vor einiger Zeit habe ich ja bereits darüber berichtet, dass meine Hündin angeblich ein Rückenleiden hat. Die Symtome waren:

Emfindliche Haut am Rücken

Wenn man sie am Rücken berührte, zog sich die Haut zusammen

Schlappheit

Sie ist sonst extrem hibbelig und nervt, wenn sie nicht min. ein mal am Tag odentlich raus kommt. In der Zeit lag sie nur rum und wollte ihre Ruhe

Ein verbreiterter Brustkorb

Die unteren Rippen standen irgendwie nach außen. Das zeigte sich aber erst im Verlauf der zweiten Woche

Extremes Zittern

Gegen Ende der zweiten Kranksheistwoche fing sie an, am ganzen Körper zu zittern. Fast durchgehend.

Die Diagnose der Ärztin war, nach kurzem abtasten des Rückens, eben Rückenleiden und die Behandlung erfolgte mit etlichen Spritzen und Kurzwellen- sowie Rotlichtbestrahlung. Als das Zittern einsetzte berichtete ich das der Ärztin, die das daraufhin als “die tut nur so” abtat. Auch nach mehrmaligem Hinweisen, dass es immer wieder etwas schlimmer wird.

Als nach über zwei Wochen noch immer keine Besserung eingetreten war, haben wir mal eine zweite Meinung eingeholt. Dieser Artz untersuchte die Zora ganze anderthalb Stunden, zog und drehte an allen Gelenken und röntgte zum Schluss, als er immer noch nichts finden konnte. Da stellte sich dann heraus, dass etwas im Magen fest saß und die anderen Symptome scheinbar nur Folgen waren. Die Bahandlung war hier lediglich Sauerkraut füttern und nach 2 Tagen war dann auch alles vorbei incl. des Zitterns.

Ob das mit dem Rücken eine Fehldiagnose war oder nicht, kann wohl niemand sagen. Vielleicht gab es das Problem ja und es kam noch ein zweites dazu. Meine Hündin macht sowas gerne. Sie hatte selten nur eine Krankheit, was ihr wohl zu langweilig ist.

Fazit

Man sollte sich schon immer auf sein Bauchgefühl verlassen, gerade wenn neue Symtome einfach abgetan oder nicht beachtet werden. Und eine zweite Meinung ist immer gut, gerade wenn sich eine ganze Weile nichts verbessert.

Die zweite Chance

Das Ganze ich schon über ein halbes Jahr her und wegen einer etwas zu groß geratenen Zecke, die ich mit der Zange nicht mehr fassen konnte weil sie zu vollgesogen war, habe ich der Ärztin nochmal eine Chance geben wollen. Diese hat sich allerdings gleich wieder was geleistet, eine Wundsalbe war nämlich schon gut 6 Monate abgelaufen. Ich konnte sie zwar anstandslos umtauschen, aber ich denke, das kontrollieren der Haltbarkeitsdaten von Arzneimitteln ist schon eine grundlegende Angelegenheit. Denn Mittel, die man mitgegeben bekommt, kann man kontrollieren solange man daran denkt. Aber was ist mit denen, die direkt verabreicht werden? Soll ich da jedes mal kontrollieren?

Fazit für mich:

Diese Ärztin, Namentlich Frau Dr. Bauer aus Wiesbaden, werde ich nicht wieder besuchen. Den Fall mit dem Rückenleiden kann man ihr zwar ankreiden, aber da kann man immer auf eine zweite Meinung zurückgreifen. Abgelaufene Arzneimittel sind für mich aber ein rotes Tuch.

Derzeit empfehlen kann ich de Praxis Dr. Kindler. Da wartet man zwar manchmal recht lange, wegen sehr viel Patientenauskommen, aber die Ärzte dort machte einen durch und durch kompetenten Eindruck. Vielleicht machen sie manchmal zu viel, so haben zumindest Leute im Warteraum erzählt, aber so herum ist es mir lieber und in diesen Fällen muss man ja einfach nur den Mund aufmachen.

Abgelegt unter Hündin Zora | 1 Kommentar »

EeePc: WLan-Probleme mit DHCP bzw. der IP

Erstellt von Tobi am Donnerstag 19. Februar 2009

Kaum hab ich Technik in der Hand gehen die Probleme schon los. Bei dem Verbinden des Eee PC 901 per WLan kam eine sehr ungewöhnliche IP-Adresse heraus die mir das DHCP zugewiesen hat. Auch ein Verbinden per statischer IP führte dazu, dass ich nur mein Gateway erreichen konnte. Andere Adressen im gleichen Netz waren nicht erreichbar.

Was genau das Problem ist, kann ich nicht sagen aber die Lösung fand ich bei einer Installationsanleitung für Ubuntu: Laptop ausschalten, Akku entfernen, Akku wieder rein und Rechner wieder starten. Und siehe da: die IP wird korrekt eingestellt und die Verbindung klappt.

Das verbaute WLan Teil ist von der gleichen Firma wie die WLan-Sticks, die auch in den letzten Aldi-Laptops verbaut wurden und mit denen hatte ich schon so einiges an schlechter Erfahrung. Stabilität der Verbindung und Kompatibilität mit Standardhardware waren da ein Problem, was hier aber, zumindest bis jetzt, mit dem EeePc keine Probleme macht.

Abgelegt unter Technik | Keine Kommentare »