Input/output error

[scientific]

Im Log tauchen immer wieder Einträge folgender Art auf:

Code: Alles auswählen

aldebaran dovecot[1968]: imap(jakob): Error: pread() failed with file /var/spool/dovecot/mails/jakob/INBOX/SYSTEM/dovecot.index.log: Input/output error

wenn ich versuche die Datei auszulesen:

Code: Alles auswählen

# cat  /var/spool/dovecot/mails/jakob/INBOX/SYSTEM/dovecot.index.log
cat: /var/spool/dovecot/mails/jakob/INBOX/SYSTEM/dovecot.index.log: Eingabe-/Ausgabefehler

Hingegen

Code: Alles auswählen

# stat dovecot.index.log 
  Datei: „dovecot.index.log“
  Größe: 4440           Blöcke: 16         EA Block: 4096   reguläre Datei
Gerät: 2ch/44d  Inode: 59097       Verknüpfungen: 1
Zugriff: (0666/-rw-rw-rw-)  Uid: (  115/ dovecot)   Gid: (  122/ dovecot)
Zugriff    : 2015-09-20 19:50:59.771955628 +0200
Modifiziert: 2015-09-20 13:28:25.207881624 +0200
Geändert   : 2015-09-20 19:42:35.519705817 +0200
 Geburt    : -

Ich vermute, dass das Dateisystem korrupt ist... es ist ein BTRFS.

Das Phänomen tritt aber nur bei dovecot auf. Und ich weiß jetzt nicht, ob es ein Problem von dovecot ist, welches beim Beenden(?) die Datei verwurschtelt, oder ob die Festplatte (ist gerade einmal 5 Monate alt) oder ob BTRFS kaputt ist.

Wie würdet ihr da genau vorgehen?

Ich kann die kaputte Datei löschen, dann läuft alles ganz normal weiter, bis nach einiger Zeit wieder ein ähnlicher Fehler auftritt.

lg scientific

[smutbert]

Wenn das Dateisystem kaputt ist sollte es doch entsprechende Meldungen vom Kernel geben - hast du das einmal nach dem Auftreten überprüft (ich verwende dazu immer dmesg, weil ich nie sicher bin wie ich mir mit journalctl nur die Kernelmeldungen anzeigen lassen kann).

Hast du das Dateisystem bereits überprüft (btrfsck) und schrubben?
Wenn ich es recht in Erinnerung habe (und es sich nicht geändert hat) weist btrfs bzw. der Kernel auch beim Mounten auf vergangene (nicht behobene?) Fehler hin.

[scientific]

Hab neu gebootet und dann dmesg nach btrfs durchforstet.

Code: Alles auswählen

# dmesg|grep -i btrfs
[    6.591020] Btrfs loaded
[    6.673024] BTRFS: device label System devid 1 transid 146742 /dev/sda4
[    6.694344] BTRFS info (device sda4): disk space caching is enabled
[   11.755357] BTRFS info (device sda4): enabling auto defrag
[   11.755360] BTRFS info (device sda4): use ssd allocation scheme
[   11.755362] BTRFS info (device sda4): turning on discard
[   11.755363] BTRFS info (device sda4): disk space caching is enabled
[   15.004625]  xt_LOG xt_limit ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp xt_conntrack nf_conntrack iptable_filter ip_tables x_tables fuse ppdev lp parport autofs4 btrfs xor raid6_pq sg sr_mod cdrom sd_mod hid_generic usbhid hid rtsx_pci_sdmmc mmc_core crc32c_intel ahci libahci r8169 mii xhci_pci i915 libata i2c_algo_bit ehci_pci scsi_mod xhci_hcd ehci_hcd drm_kms_helper rtsx_pci mfd_core usbcore drm usb_common thermal wmi video thermal_sys button

So wie es aussieht, scheint das Dateisystem doch nicht korrupt zu sein.

fsck hab ich noch nicht laufen lassen, da ich dazu erst einen Repair-Stick bauen muss (hab momentan kein Reparatur-Live-System).

Ich hab mal so nachgedacht, welche Files da in der Vergangenheit schon aufgefallen sind...

Es waren eigentlich immer dovecot.index.log oder dovecot.index in verschiedenen Verzeichnissen von Dovecot.
Also scheint das eher ein Problem von Dovecot zu sein, das unlesbare Dateien produziert... Möglicherweise beim shutdown des Systems... aber das ist nur ein Schuß ins Blaue... Da ich auch nicht sagen kann, wann das Problem auftritt. Ich bemerkte es bisher nur eher zufällig, wenn ich irgend einen Dienst neu startete und dabei journalctl -f in einem zweiten Terminal laufen ließ.

lg scientific

[scientific]

Mailserver- (Exim4)experten scheinen auch im anderen Forum zu weilen...

[smutbert]

Ja, also ich bin der letzte der sich mit Mailservern oder exim auskennt, aber dafür habe ich einen Hinweis gefunden, dass btrfs nicht das einzige Dateisystem ist, mit dem icedove in Zusammenhang mit der dovecot.index.log möglicherweise Probleme verursacht:
http://www.dovecot.org/list/dovecot/200 ... 26548.html

[scientific]

Ja, also ich bin der letzte der sich mit Mailservern oder exim auskennt, aber dafür habe ich einen Hinweis gefunden, dass btrfs nicht das einzige Dateisystem ist, mit dem icedove in Zusammenhang mit der dovecot.index.log möglicherweise Probleme verursacht:
http://www.dovecot.org/list/dovecot/200 ... 26548.html

Vielen Dank. Das ist zumindest auch schon etwas, wo ich weiterforschen kann. Hab mal probiert mmap_disable = yes... Mal sehen, ob das etwas bringt. Wird zumindest vorgeschlagen in deinem LInk.

lg scientific

[smutbert]

Mich erinnert das halt auch irgendwie an die Probleme, die es zB mit Images von virtuellen Maschinen zu Beginn mit btrfs gegeben hat. Da war es - egal ob es um qemu, virtualbox oder eine andere Software ging - auch nur eine Frage der Zeit bis btrfs Fehler geliefert hat, nur ist das gefühlt schon so lange her, dass ich eigentlich nicht mehr mit etwas in der Art gerechnet hätte.

Jedenfalls steht in meinem Link auch der Hinweis auf die Kernelmeldungen/dmesg. Es wäre schon interessant ob da irgendetwas ausgegeben wurde, etwa bei dem Versuch die Datei mit cat zu lesen.

[scientific]

Das seltsame ist, jetzt sind die Fehlermeldungen und unlesbaren Dateien schon länger nicht mehr aufgetreten... Ich kanns es also momentan nicht nachvollziehen.

Allerdings gab es heute noch ein anderes Problem (habe exim versucht über systemd-socket-activation zu betreiben), dass das paniclog lt. journalctl IO-Fehler lieferte, aber mit cat war as File problemlos auszulesen.
Jetzt hab ich exim wieder auf "Normalbetrieb" umgestellt und die Fehlermeldungen bzgl. Dateisystemfehler verschwanden wieder...

Exim scheint nicht ganz soooo stabil zu sein, hab ich den Eindruck. Oder ist es wirklich die Kombi exim4 mit systemd und btrfs?

lg scientific