Disk I/O Error beim bereinigen der fhem.db

franky08 · 26 April 2016, 17:30:43

Hallo, wenn ich z.B. mit:

sqlite> delete from history where TIMESTAMP like "2015%";

alle alten Datensätze von 2015 löschen möchte, quittiert der Host nach einiger Zeit mit "Error: disk I/O error".
Danach ist die SSD nur noch read-only gemountet (steht so in der fstab, damit man noch vom System z.B. die Log´s lesen kann).

Code Auswählen

sudo: unable to open /var/lib/sudo/frank1/0: Das Dateisystem ist nur lesbar
sudo: unable to execute /sbin/shutdown: Input/output error
frank1@zotac:/opt/fhem$

Dann hilft nur noch der Power Schalter.
Sonst funktioniert seit 2 Jahren das System ohne Probleme nur das löschen der alten Daten aus der fhem.db bringt den I/O Error.

Hat jemand eine Idee?

VG
Frank

CoolTux · 26 April 2016, 17:35:10

Mach mal im nicht gemounteten Zustand ein fsck.

betateilchen · 26 April 2016, 17:51:41

Warum kopierst Du nicht einfach die neueren Datensätze in eine neue Tabelle? Da geht doch viel schneller und belastet die Festplatte sehr viel weniger. Du solltest immer daran danken, dass standardmässig ein journalierendes Dateisystem verwendet wird, da steigen die I/O Zugriffe bei Deinem Löschvorgang drastisch an, bis entweder das Journal oder die Festplatte selbst ins Chaos stürzen.

Wernieman · 26 April 2016, 18:31:32

I/O-Error bedeuten, was der Fehler aussagt:
Hardwarefehler im I/O-Bereich. Also entweder SATA-Kontroller oder SSD. Für weitere Hilfe: Was für ein System hast Du?

Zusatzinfo:
Die SSD wird im Fehlerfall ro gemountet, damit das System noch rettbar ist. Ein echtes Ausschalten ist trotzem nicht empfehlenswert. Also trotzdem versuchen das System runterzufahren.

Edit:
Laut Signatur hast Du eine ZBox nano. kannst Du:
1) per smartctrl Deine ssd prüfen?

Code Auswählen


smartctl -a /Deine/Festplatte
smartctl -t long /Deine/Festplatte

2) wie schon geschrieben: mit einem Alternativmedium booten und per fsck prüfen?

Code Auswählen

fsck /Deine/Festplatte
3) Kernlog nach i/o Fehlern prüfen?

Code Auswählen

zgrep -i i/o /var/log/kern.log*

justme1968 · 26 April 2016, 18:44:50

unabhängig vom vermutlichen hardware fehler: bei sqlite darf
nur ein prozess schreibend auf die db zugreifen. wenn du also die sqlite shell so verwendest sollte FHEM nicht
gleichzeitig laufen und in die db schreiben.

gruss
andre

franky08 · 26 April 2016, 18:57:30

Das war mir klar, hatte fhem vorher mittels shutdown ausgeschaltet, fscck ist mittlerweile bei 90% und biher ohne Error durchgelaufen. Das ist wohl so, wie betateilchen schon geschrieben hat. Kernel log hab ich schon überprüft, da ist nichts auffälliges zu finden. Da das auch mit einer neuen ssd passiert, fhem.db mittels dump importiert, kann ich die ssd als Fehlerquelle wohl ausschließen, dass wäre schon ein riesiger Zufall, dass zwei Platten den gleiche Fehler beim aufräumen der DB melden. Ich denke das es so ist wie betateilchen schon geschrieben hat, die DB hat ja mittlerweile 11Gb.

VG
Frank

CoolTux · 26 April 2016, 19:01:21

Naja alleine an der Größe wird es nicht liegen. Wir fahren hier Datenbanken mit mehreren 100Gb Größe.
Es könnte aber vielleicht an sqlite liegen.

betateilchen · 26 April 2016, 19:09:57

Zitat von: CoolTux am 26 April 2016, 19:01:21
Wir fahren hier Datenbanken mit mehreren 100Gb Größe.

wir auch, aber nicht

auf sqlite
auf einer zbox

franky08 · 26 April 2016, 19:11:41

ich starte den Host/fhem jetzt erst mal wieder, die Wohnung wird kalt

P.S. @Wernieman -bash: smartctl: Kommando nicht gefunden., scheint er nicht zu kennen, kern.log* ohne Einträge i/o betreffend

VG
Frank

Wernieman · 26 April 2016, 19:32:15

dann einfach installieren ;o)

Was mich wundert: Wenn sql-light ein Problem hat, wird das Dateisystem nicht vom Kernel read-only-gemountet. Läuft schließlich nicht mit root-Rechten. Währe das erste mal ain meinem leben als Systemadministrator, das ich einen i/o-Fehler durch eine Software erzeugen kann ... (Abgesehen vom Treiber)

Ansonsten könntest Du deine System stressen .. einfach um sicherzugehen.

betateilchen · 26 April 2016, 19:42:27

Zitat von: Wernieman am 26 April 2016, 19:32:15
Ansonsten könntest Du deine System stressen .. einfach um sicherzugehen.

Muss er nicht. Den beschriebenen i/o Fehler bei solchen sqlite Operationen kann ich auch bei mir zuverlässig reproduzieren. Aber nur auf SSD Platten, auf mechanischen Platten ist das hier noch nie passiert.

Wernieman · 26 April 2016, 19:48:00

Bis zum read-only-mounten der Platte?

Hast Du ein einfach reprodurierbare Möglichkeit? Würde es sonst hier mal testen ... habe nur keine sql-lite db

betateilchen · 26 April 2016, 19:56:47

Zitat von: Wernieman am 26 April 2016, 19:48:00
Bis zum read-only-mounten der Platte?

Ja, die Platte (das zugehörige kernelmodul) meldet einen Fehler und der Kernel macht daraufhin ein ro-remount, weil das so in der /etc/fstab steht.

Wernieman · 26 April 2016, 20:12:32

Habe es nur noch nie erlebt, das durch Überlastung der sata-Kerneltreiber "sich in die Hosen" macht ... deshalb meine Frage nach einem einfachen setup ...

franky08 · 28 April 2016, 09:00:51

So, dann melde ich mich noch mal zurück. Habe jetzt ein zweites System mit einer "mechanischen Platte" aufgesetzt, da mir der zotac mit SSD jedesmal in´s Nirvana geht wenn ich die fhem.db aufräumen möchte.
Die "große" Frage ist: Wie bekomme ich die DB vom alten System auf das Neue?
sqlite3 fhem.db .dump>fhem_dump.sql funktioniert nicht denn da bekomme ich nach kurzer Zeit wieder den I/O Error und der Host verabschiedet sich.

VG
Frank

P.S. mit einer kleineren Db (ich logge die Energiedaten in eine zweite Db) kann ich einen dump machen, die Datenbank ist aber auch wesentlich kleiner