Ich wollte eigentlich eine Frage stellen, aber mir passiert es öfters, dass wenn ich ein Problem für ein Forum akkurate beschreiben will, ich selbst auf die Lösung komme. Ich poste es jetzt trotzdem.
Ich habe meinem selbstbau-NAS mehr RAM und eine weitere Festplatte spendiert. Dummerweise hab ich den RAM nicht richtig reingesteckt und nicht bemerkt. Und in diesem Zustand hab den RAID-reshape (mdadm --add + mdadm --grow) angeworfen.
Dabei sind eventuell Datenbereiche korrumpiert und nach ein paar Stunden ist die Kiste abgestürzt.
Nach dem reboot will das filesystem (xfs) nicht mehr mounten und der mount-Prozess bleibt hängen, und zwar mit einer hässlichen Kernel-Fehlermeldung im syslog:
xfs_check läuft durch, aber xfs_repair bleibt in der selben Weise hängen. Die layer darunter (physisch, raid, crypto) liefen alle, zumindest lesend, wie ich mit dd testen konnte. So, und dann dämmerte es mir, das lesende Operationen alle gehen, die eine schreibende (xfs_repair) aber nicht. Und des weiteren ist mir aufgefallen, dass ein "cat /proc/mdstat" mir angezeigt hat, dass das raid im read only modus ist. Das ist eigentlich normal und auch richtig, und eigentlich sollte sich das raid automatisch selbst in den Schreibmodus umstellen, sobald eine Schreiboperation ankommt. Das hat aber anscheinend nicht geklappt. Nach einem "mdadm --readwrite /dev/md0" ging dann xfs_repair, das hat ein paar Fehler gefixt und danach ging auch wieder mounten.
Ein Mysterium ist noch, warum initial das mounten nicht ging. Meine Vermutung ist, dass er versucht hat, das Journal abzuarbeiten.
Es hat sich mal wieder bestätigt, raid ersetzt kein Backup. Ob ich bei Aktion jetzt Daten außerhalb des Journals verloren hab, kann ich nicht mal sagen. Das Dateisystem ist immerhin ähnlich voll wie vorher und Konsistent/Fehlerfrei.
Ich habe meinem selbstbau-NAS mehr RAM und eine weitere Festplatte spendiert. Dummerweise hab ich den RAM nicht richtig reingesteckt und nicht bemerkt. Und in diesem Zustand hab den RAID-reshape (mdadm --add + mdadm --grow) angeworfen.
Dabei sind eventuell Datenbereiche korrumpiert und nach ein paar Stunden ist die Kiste abgestürzt.Nach dem reboot will das filesystem (xfs) nicht mehr mounten und der mount-Prozess bleibt hängen, und zwar mit einer hässlichen Kernel-Fehlermeldung im syslog:
Code:
Aug 12 11:16:06 servername kernel: [ 241.820858] INFO: task mount:3898 blocked for more than 120 seconds.
Aug 12 11:16:06 servername kernel: [ 241.820900] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 12 11:16:06 servername kernel: [ 241.820941] mount D ffff8801afc927c0 0 3898 3784 0x00000000
Aug 12 11:16:06 servername kernel: [ 241.820950] ffff8801a7448840 0000000000000086 000000000000021b ffff8801a8f23880
Aug 12 11:16:06 servername kernel: [ 241.820958] 00000000000127c0 ffff8801a6b37fd8 ffff8801a6b37fd8 ffff8801a7448840
Aug 12 11:16:06 servername kernel: [ 241.820967] 0000000000000001 ffffffff8119a70c 0000000000000000 7fffffffffffffff
Aug 12 11:16:06 servername kernel: [ 241.820975] Call Trace:
Aug 12 11:16:06 servername kernel: [ 241.820983] [<ffffffff8119a70c>] ? generic_make_request+0x90/0xcf
Aug 12 11:16:06 servername kernel: [ 241.820991] [<ffffffff8135020b>] ? schedule_timeout+0x2c/0xdb
Aug 12 11:16:06 servername kernel: [ 241.821049] [<ffffffffa0229e87>] ? _xfs_buf_ioapply+0x17a/0x1bb [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821057] [<ffffffff8134fe51>] ? wait_for_common+0xa0/0x119
Aug 12 11:16:06 servername kernel: [ 241.821064] [<ffffffff8103f751>] ? try_to_wake_up+0x197/0x197
Aug 12 11:16:06 servername kernel: [ 241.821097] [<ffffffffa022a87b>] ? xfs_bwrite+0x29/0x5c [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821129] [<ffffffffa0229ff2>] ? xfs_buf_iowait+0x44/0x81 [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821162] [<ffffffffa022a87b>] ? xfs_bwrite+0x29/0x5c [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821207] [<ffffffffa0261c92>] ? xlog_bwrite+0x60/0xc2 [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821252] [<ffffffffa0262f3d>] ? xlog_write_log_records+0x178/0x1bd [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821297] [<ffffffffa0263354>] ? xlog_find_tail+0x291/0x2f4 [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821306] [<ffffffff81351167>] ? _raw_spin_unlock_irqrestore+0xe/0xf
Aug 12 11:16:06 servername kernel: [ 241.821343] [<ffffffffa023611e>] ? xfs_parseargs+0xa0f/0xa0f [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821388] [<ffffffffa0264fda>] ? xlog_recover+0x15/0x78 [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821435] [<ffffffffa026b047>] ? xfs_log_mount+0xc4/0x12c [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821480] [<ffffffffa0267242>] ? xfs_mountfs+0x2d8/0x55e [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821516] [<ffffffffa0236295>] ? xfs_fs_fill_super+0x177/0x255 [xfs]
Aug 12 11:16:06 servername kernel: [ 241.821527] [<ffffffff810fd6e9>] ? mount_bdev+0x14a/0x1ac
Aug 12 11:16:06 servername kernel: [ 241.821535] [<ffffffff810ed3ac>] ? __kmalloc_track_caller+0xfe/0x110
Aug 12 11:16:06 servername kernel: [ 241.821546] [<ffffffff810fdf59>] ? mount_fs+0x61/0x144
Aug 12 11:16:06 servername kernel: [ 241.821556] [<ffffffff81111116>] ? vfs_kern_mount+0x5f/0x99
Aug 12 11:16:06 servername kernel: [ 241.821565] [<ffffffff81111500>] ? do_kern_mount+0x49/0xd8
Aug 12 11:16:06 servername kernel: [ 241.821573] [<ffffffff81112b9b>] ? do_mount+0x680/0x6e6
Aug 12 11:16:06 servername kernel: [ 241.821583] [<ffffffff810ca3b4>] ? memdup_user+0x36/0x5b
Aug 12 11:16:06 servername kernel: [ 241.821590] [<ffffffff81112ea9>] ? sys_mount+0x88/0xc3
Aug 12 11:16:06 servername kernel: [ 241.821597] [<ffffffff813561b2>] ? system_call_fastpath+0x16/0x1bxfs_check läuft durch, aber xfs_repair bleibt in der selben Weise hängen. Die layer darunter (physisch, raid, crypto) liefen alle, zumindest lesend, wie ich mit dd testen konnte. So, und dann dämmerte es mir, das lesende Operationen alle gehen, die eine schreibende (xfs_repair) aber nicht. Und des weiteren ist mir aufgefallen, dass ein "cat /proc/mdstat" mir angezeigt hat, dass das raid im read only modus ist. Das ist eigentlich normal und auch richtig, und eigentlich sollte sich das raid automatisch selbst in den Schreibmodus umstellen, sobald eine Schreiboperation ankommt. Das hat aber anscheinend nicht geklappt. Nach einem "mdadm --readwrite /dev/md0" ging dann xfs_repair, das hat ein paar Fehler gefixt und danach ging auch wieder mounten.
Ein Mysterium ist noch, warum initial das mounten nicht ging. Meine Vermutung ist, dass er versucht hat, das Journal abzuarbeiten.
Es hat sich mal wieder bestätigt, raid ersetzt kein Backup. Ob ich bei Aktion jetzt Daten außerhalb des Journals verloren hab, kann ich nicht mal sagen. Das Dateisystem ist immerhin ähnlich voll wie vorher und Konsistent/Fehlerfrei.