13
Debian 8.5 mit FAKE Raid - rsync und cp verursachen Systemabsturtz
Hallo die Damen und Herren,
nach langer Zeit hab ich mal wieder ein Problemchen wo pure Ratlosigkeit zum Vorschein tritt und ich mal euer Wissen bräuchte.
Ich befinde mich eine Samba ADS Umgebung.
Ich habe hier einen Debian System, welches als Fileserver eingesetzt wird. Dieses System hat eine einfache Dateifreigabe welche nachts auf einen anderen Server mit rsync synchronisiert wird.
Bisher lag die Freigabe auf einer HDD mit EXT4. Die synchronisierung verlief immer problemlos.
Wir haben dann dem System ein Raid1 mit zwei SSD's spendiert um den Datenzugriff etwas zu optimieren.
Das Ganze läuft also über ein Raid des Motherboards. Diese Hardwareraids über das Motherboard ohne extra Raidkarte werden ja nun von Linux als FAKE Raid behandelt.
Ich muss seltsamerweise das Raid per Hand mounten da das Einbinden über die fstab nicht funktioniert. Das System boote nicht.
Ich nutze folgende Befehl um das Raid zu mounten:
sudo mount /dev/mapper/ddf1_Raid1 /Datenverzeichnis
Des Weiteren habe ich einen Backupserver auch mit Debian 8.5 als Memberserver.
Wenn ich die Verzeichnisse nun nachts synchronisieren will friert mir der Backupserver ein. Ich kann mich dann weder am Server direkt noch über SSH oder RDP am Server anmelden.
Ich muss den Server reseten um drauf zugreifen zu können. Die Logfiles ergeben keine Hinweise. Ich bin ehrlich ich weiß allerdings auch nicht was ich zusätzlich noch loggen könnte um mehr Informationen zu erhalten. Ich habe heute jedes Unterverzeichnis einzeln synchronisiert selbst da ist der Backupserver eingefroren. Nach dem Reboot habe ich beim letzten Verzeichnis neu angesetzt und konnte den Rest problemlos synchronisieren.
Nun würde ich von der Logik her sagen ok der Fehler liegt am Backup Server. Haken dabei ist das ich einen anderen Server ohne Raid am Samstag problemlos synchronisert habe.
Freitag habe ich auf dem Fileserver sellbst versucht vom Raid auf die verbliebene HDD zu synchronisieren mit rsync: Systemfreeze
Letzten Sonntag als Cronjob einen copy Befehl der Montag morgen zu einem nicht exsistenen Laufwerk führte.
Somit Tippe ich auf das Raidsystem. Auf dem Filserver in den besagten Zeiträumen keinerlei hinweisende Fehler die mich weiter bringen würden.
Da es sich um eine Sambafreigabe handelt kopiere ich natürlich die Berechtigungen mit.
Hat jemand sowas schon mal erlebt oder kann mir weitere Hinweise geben wo ich ansetzen kann?
Gruß Andreas
nach langer Zeit hab ich mal wieder ein Problemchen wo pure Ratlosigkeit zum Vorschein tritt und ich mal euer Wissen bräuchte.
Ich befinde mich eine Samba ADS Umgebung.
Ich habe hier einen Debian System, welches als Fileserver eingesetzt wird. Dieses System hat eine einfache Dateifreigabe welche nachts auf einen anderen Server mit rsync synchronisiert wird.
Bisher lag die Freigabe auf einer HDD mit EXT4. Die synchronisierung verlief immer problemlos.
Wir haben dann dem System ein Raid1 mit zwei SSD's spendiert um den Datenzugriff etwas zu optimieren.
Das Ganze läuft also über ein Raid des Motherboards. Diese Hardwareraids über das Motherboard ohne extra Raidkarte werden ja nun von Linux als FAKE Raid behandelt.
Ich muss seltsamerweise das Raid per Hand mounten da das Einbinden über die fstab nicht funktioniert. Das System boote nicht.
Ich nutze folgende Befehl um das Raid zu mounten:
sudo mount /dev/mapper/ddf1_Raid1 /Datenverzeichnis
Des Weiteren habe ich einen Backupserver auch mit Debian 8.5 als Memberserver.
Wenn ich die Verzeichnisse nun nachts synchronisieren will friert mir der Backupserver ein. Ich kann mich dann weder am Server direkt noch über SSH oder RDP am Server anmelden.
Ich muss den Server reseten um drauf zugreifen zu können. Die Logfiles ergeben keine Hinweise. Ich bin ehrlich ich weiß allerdings auch nicht was ich zusätzlich noch loggen könnte um mehr Informationen zu erhalten. Ich habe heute jedes Unterverzeichnis einzeln synchronisiert selbst da ist der Backupserver eingefroren. Nach dem Reboot habe ich beim letzten Verzeichnis neu angesetzt und konnte den Rest problemlos synchronisieren.
Nun würde ich von der Logik her sagen ok der Fehler liegt am Backup Server. Haken dabei ist das ich einen anderen Server ohne Raid am Samstag problemlos synchronisert habe.
Freitag habe ich auf dem Fileserver sellbst versucht vom Raid auf die verbliebene HDD zu synchronisieren mit rsync: Systemfreeze
Letzten Sonntag als Cronjob einen copy Befehl der Montag morgen zu einem nicht exsistenen Laufwerk führte.
Somit Tippe ich auf das Raidsystem. Auf dem Filserver in den besagten Zeiträumen keinerlei hinweisende Fehler die mich weiter bringen würden.
Da es sich um eine Sambafreigabe handelt kopiere ich natürlich die Berechtigungen mit.
Hat jemand sowas schon mal erlebt oder kann mir weitere Hinweise geben wo ich ansetzen kann?
Gruß Andreas
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 313858
Url: https://administrator.de/contentid/313858
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
13 Kommentare
Neuester Kommentar
Hallo,
Gruß
Chonta
Freitag habe ich auf dem Fileserver sellbst versucht vom Raid auf die verbliebene HDD zu synchronisieren mit rsync: Systemfreeze
Also auf dem Dateiserver war noch eine lokale Festplatte und DU hast auf dem Dateiserver von der SSD auf die lokale HDD mit rsync copiert und dabei den Dateiserver abgeschossen?Gruß
Chonta
Zitat von @backara:
Das Ganze läuft also über ein Raid des Motherboards. Diese Hardwareraids über das Motherboard ohne extra Raidkarte werden ja nun von Linux als FAKE Raid behandelt.
Das Ganze läuft also über ein Raid des Motherboards. Diese Hardwareraids über das Motherboard ohne extra Raidkarte werden ja nun von Linux als FAKE Raid behandelt.
Waum dieser Mist un dnciht gleich rodentlich mit md-raid, wenn man sich schon Software-raid antut?
Ich muss seltsamerweise das Raid per Hand mounten da das Einbinden über die fstab nicht funktioniert.
Fehlermeldung? Syslogs?
Das System boote nicht.
Ich nutze folgende Befehl um das Raid zu mounten:
sudo mount /dev/mapper/ddf1_Raid1 /Datenverzeichnis
Ich nutze folgende Befehl um das Raid zu mounten:
sudo mount /dev/mapper/ddf1_Raid1 /Datenverzeichnis
Und was steht in der fstab?
Des Weiteren habe ich einen Backupserver auch mit Debian 8.5 als Memberserver.
Wenn ich die Verzeichnisse nun nachts synchronisieren will friert mir der Backupserver ein. Ich kann mich dann weder am Server direkt noch über SSH oder RDP am Server anmelden.
Ich muss den Server reseten um drauf zugreifen zu können. Die Logfiles ergeben keine Hinweise. Ich bin ehrlich ich weiß allerdings auch nicht was ich zusätzlich noch loggen könnte um mehr Informationen zu erhalten. Ich habe heute jedes Unterverzeichnis einzeln synchronisiert selbst da ist der Backupserver eingefroren. Nach dem Reboot habe ich beim letzten Verzeichnis neu angesetzt und konnte den Rest problemlos synchronisieren.
Wenn ich die Verzeichnisse nun nachts synchronisieren will friert mir der Backupserver ein. Ich kann mich dann weder am Server direkt noch über SSH oder RDP am Server anmelden.
Ich muss den Server reseten um drauf zugreifen zu können. Die Logfiles ergeben keine Hinweise. Ich bin ehrlich ich weiß allerdings auch nicht was ich zusätzlich noch loggen könnte um mehr Informationen zu erhalten. Ich habe heute jedes Unterverzeichnis einzeln synchronisiert selbst da ist der Backupserver eingefroren. Nach dem Reboot habe ich beim letzten Verzeichnis neu angesetzt und konnte den Rest problemlos synchronisieren.
Du könntest z.B. regelmäßig den load aufzeichnen lassen, ob da vielleicht etwas hochschnellt. (http://www.thegeekstuff.com/2011/03/sar-examples/)
Nun würde ich von der Logik her sagen ok der Fehler liegt am Backup Server. Haken dabei ist das ich einen anderen Server ohne Raid am Samstag problemlos synchronisert habe.
Geht das immer noch? Es kann auch Zufall sein, dass beides zusammenfällt.
Freitag habe ich auf dem Fileserver sellbst versucht vom Raid auf die verbliebene HDD zu synchronisieren mit rsync: Systemfreeze
Letzten Sonntag als Cronjob einen copy Befehl der Montag morgen zu einem nicht exsistenen Laufwerk führte.
Somit Tippe ich auf das Raidsystem. Auf dem Filserver in den besagten Zeiträumen keinerlei hinweisende Fehler die mich weiter bringen würden.
Da es sich um eine Sambafreigabe handelt kopiere ich natürlich die Berechtigungen mit.
Hat jemand sowas schon mal erlebt oder kann mir weitere Hinweise geben wo ich ansetzen kann?
Letzten Sonntag als Cronjob einen copy Befehl der Montag morgen zu einem nicht exsistenen Laufwerk führte.
Somit Tippe ich auf das Raidsystem. Auf dem Filserver in den besagten Zeiträumen keinerlei hinweisende Fehler die mich weiter bringen würden.
Da es sich um eine Sambafreigabe handelt kopiere ich natürlich die Berechtigungen mit.
Hat jemand sowas schon mal erlebt oder kann mir weitere Hinweise geben wo ich ansetzen kann?
Fake-RAID auflösen und mit mdadm md-raids backen.
lks
@Lochkartenstanzer
Ich war so frei, deinen Beitrag von den typografischen Fehlerchen zu befreien
tomolpi
Ich war so frei, deinen Beitrag von den typografischen Fehlerchen zu befreien
tomolpi
Zitat von @tomolpi:
@Lochkartenstanzer
Ich war so frei, deinen Beitrag von den typografischen Fehlerchen zu befreien
@Lochkartenstanzer
Ich war so frei, deinen Beitrag von den typografischen Fehlerchen zu befreien
danke.
lks
Hallo Chonta,
richtig beim rsync von SSD auf HDD intern ist der Filserver abgestürtzt.
genau wie bei dem Copy Befehl.
hier mal beide Befehle die ich genutzt habe.
rsync dabei als sudo und cp als crontab
Gruß Andreas
richtig beim rsync von SSD auf HDD intern ist der Filserver abgestürtzt.
genau wie bei dem Copy Befehl.
hier mal beide Befehle die ich genutzt habe.
rsync dabei als sudo und cp als crontab
rsync –aAs --log-file=/beispiel.log /DatenQuelle /DatenZiel
cp –a –p –R /DatenQuelle /DatenZielGruß Andreas
Gibt es eine coredump? Was steht in den kernellogs?
lks
lks
Hi lks,
ich habe den Begriff Fake Raid genutzt weil ich ihn so bei meiner Suche bisher gelesen habe.
Es ist ein Hardwareraid über das Mainboard.
dmraid ist installiert und die Festplattenverwaltung zeigt /dev/dm-0 als Laufwerk an.
Ich hatte in der fstab folgenden Eintrag:
wie oben geschrieben mounte ich manuell und das funktioniert soweit.
Fehlermeldungen bzw Syslog mit relevanten Hinweisen gibt es zur Ausfallzeit nicht. Weder beim Fileserver noch beim Backupserver.
Ich habe mitlerweile mein Skript so umgeschrieben, dass ich die Verzeichnisse einzeln mit rsync synchronisiere. Jeweils mit einem sleep von 1 Minute zwischen den Befehlen. Das hab ich heute morgen manuell zum Testen ausgeführt und hat geklappt.
Bis ich der Lösung des Problems auf die Schliche komme werde ich versuchen heute als erstes das Skript als Cron auszuführen.
Ich kann mir diesen Sachverhalt nicht erklären. Meine Vermutung liegt beim Einbinden des Raids.
Gruß Andreas
ich habe den Begriff Fake Raid genutzt weil ich ihn so bei meiner Suche bisher gelesen habe.
Es ist ein Hardwareraid über das Mainboard.
dmraid ist installiert und die Festplattenverwaltung zeigt /dev/dm-0 als Laufwerk an.
Ich hatte in der fstab folgenden Eintrag:
/dev/mapper/ddf1_Raid1 /Daten ext4 defaults 1 2mount /dev/mapper/ddf1_Raid1 /DatenIch habe mitlerweile mein Skript so umgeschrieben, dass ich die Verzeichnisse einzeln mit rsync synchronisiere. Jeweils mit einem sleep von 1 Minute zwischen den Befehlen. Das hab ich heute morgen manuell zum Testen ausgeführt und hat geklappt.
Bis ich der Lösung des Problems auf die Schliche komme werde ich versuchen heute als erstes das Skript als Cron auszuführen.
Ich kann mir diesen Sachverhalt nicht erklären. Meine Vermutung liegt beim Einbinden des Raids.
Gruß Andreas
Nein es gibt keinen coredump und in den kernellogs steht im Zeitraum den es Betrifft keine Information.
Erst der komplette Neustart wurde wieder geloggt. Lediglich von gestern gibt es eine Zeile.
Wenn es sinnvoll erscheint, kann ich auch den kompletten log des Reboots mal reinsetzen.
Gruß Andreas
Erst der komplette Neustart wurde wieder geloggt. Lediglich von gestern gibt es eine Zeile.
Aug 29 09:03:37 server kernel: [242155.845157] perf interrupt took too long (2508 > 2500), lowering kernel.perf_event_max_sample_rate to 50000Gruß Andreas
Guten Morgen,
nach dem letzten Task von gestern Abend, bei dem der BackupServer wieder abgestürtzt ist, habe ich nun zumindest Daten im kern.log
Ich habe den log eingekürzt da die CPU Informationen mehrfach aufgeführt werden.
Vorab noch die Info das diese Problematik erst seit dem Raid besteht. Ich hatte letzte Woche erst das System auf dem Backup Server neu aufgesetzt. Das Alte und Neue System weisen jedoch das gleiche Fehlverhalten auf.
Hier nun der Log
Wie sich erkennen lässt heute morgen der Reboot.
Die Leerzeilen am Ende sind mit NULL gefüllt.
Gruß Andreas
nach dem letzten Task von gestern Abend, bei dem der BackupServer wieder abgestürtzt ist, habe ich nun zumindest Daten im kern.log
Ich habe den log eingekürzt da die CPU Informationen mehrfach aufgeführt werden.
Vorab noch die Info das diese Problematik erst seit dem Raid besteht. Ich hatte letzte Woche erst das System auf dem Backup Server neu aufgesetzt. Das Alte und Neue System weisen jedoch das gleiche Fehlverhalten auf.
Hier nun der Log
Aug 31 19:09:29 server kernel: [208104.525559] BUG: unable to handle kernel paging request at 0000000113382d84
Aug 31 19:09:29 server kernel: [208104.525598] IP: [<ffffffff8118d344>] free_block+0x124/0x1c0
Aug 31 19:09:29 server kernel: [208104.525624] PGD 0
Aug 31 19:09:29 server kernel: [208104.525635] Oops: 0002 [#1] SMP
Aug 31 19:09:29 server kernel: [208104.525649] Modules linked in: dm_crypt dm_mod usb_storage arc4 ecb md4 hmac cfg80211 rfkill nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc nls_utf8 cifs dns_resolver fscache x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic intel_rapl snd_hda_intel snd_hda_controller coretemp snd_soc_rt5640 snd_soc_rl6231 snd_soc_core kvm_intel snd_hda_codec snd_compress snd_hwdep kvm snd_pcm crc32_pclmul snd_timer aesni_intel aes_x86_64 lrw i915 drm_kms_helper snd ppdev evdev pcspkr gf128mul soundcore serio_raw drm glue_helper ablk_helper cryptd i2c_algo_bit regmap_i2c i2c_designware_platform i2c_designware_core mei_me parport_pc shpchp snd_soc_sst_acpi mei parport video battery button processor acpi_pad fuse autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common ahci libahci crc32c_intel libata psmouse scsi_mod ehci_pci ehci_hcd xhci_hcd r8169 mii usbcore usb_common thermal fan thermal_sys sdhci_acpi sdhci mmc_core i2c_hid hid i2c_core
Aug 31 19:09:29 server kernel: [208104.526056] CPU: 2 PID: 38 Comm: kswapd0 Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 19:09:29 server kernel: [208104.526086] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 19:09:29 server kernel: [208104.526114] task: ffff88011a191630 ti: ffff88011a194000 task.ti: ffff88011a194000
Aug 31 19:09:29 server kernel: [208104.526137] RIP: 0010:[<ffffffff8118d344>] [<ffffffff8118d344>] free_block+0x124/0x1c0
Aug 31 19:09:29 server kernel: [208104.526166] RSP: 0018:ffff88011a197ba8 EFLAGS: 00010082
Aug 31 19:09:29 server kernel: [208104.526184] RAX: 00000000fffffffe RBX: ffff8800d2be95e0 RCX: 0000000013382d86
Aug 31 19:09:29 server kernel: [208104.526207] RDX: 0000000001f364de RSI: ffffea00007023e0 RDI: dead000000000200
Aug 31 19:09:29 server kernel: [208104.526229] RBP: ffff88011a9fc4c0 R08: ffff880037178540 R09: 0000000000000000
Aug 31 19:09:29 server kernel: [208104.526252] R10: 0000000000000000 R11: ffffffffffffffdc R12: 0000000080000000
Aug 31 19:09:29 server kernel: [208104.526275] R13: ffffea0000000000 R14: 000077ff80000000 R15: ffff8800d2be95f8
Aug 31 19:09:29 server kernel: [208104.526297] FS: 0000000000000000(0000) GS:ffff88011fb00000(0000) knlGS:0000000000000000
Aug 31 19:09:29 server kernel: [208104.526323] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 31 19:09:29 server kernel: [208104.526341] CR2: 0000000113382d84 CR3: 0000000001813000 CR4: 00000000001407e0
Aug 31 19:09:29 server kernel: [208104.526364] Stack:
Aug 31 19:09:29 server kernel: [208104.526372] 0000000000000000 ffff8800d2be9400 000000000000003c ffff880037178540
Aug 31 19:09:29 server kernel: [208104.526399] ffff8800d2be9418 ffff88011a9fc4c0 0000000000000000 ffffffff8150cc2c
Aug 31 19:09:29 server kernel: [208104.526425] ffff8800d2be9400 ffff880017add5d8 ffff88011a9fc4c0 0000000000000286
Aug 31 19:09:29 server kernel: [208104.526452] Call Trace:
Aug 31 19:09:29 server kernel: [208104.526466] [<ffffffff8150cc2c>] ? cache_flusharray+0x78/0xa2
Aug 31 19:09:29 server kernel: [208104.526486] [<ffffffff8118d132>] ? kmem_cache_free+0x142/0x1e0
Aug 31 19:09:29 server kernel: [208104.526521] [<ffffffffa00a10b6>] ? __mb_cache_entry_forget.isra.2+0x16/0x20 [mbcache]
Aug 31 19:09:29 server kernel: [208104.526550] [<ffffffffa00a2153>] ? mb_cache_shrink_scan+0x103/0x1e0 [mbcache]
Aug 31 19:09:29 server kernel: [208104.527497] [<ffffffff8114d367>] ? shrink_slab_node+0x127/0x290
Aug 31 19:09:29 server kernel: [208104.528422] [<ffffffff811a1aa5>] ? vmpressure+0x45/0x80
Aug 31 19:09:29 server kernel: [208104.529361] [<ffffffff8114ecf2>] ? shrink_slab+0x82/0x150
Aug 31 19:09:29 server kernel: [208104.530287] [<ffffffff8115248e>] ? balance_pgdat+0x3be/0x5c0
Aug 31 19:09:29 server kernel: [208104.531203] [<ffffffff811527ef>] ? kswapd+0x15f/0x3f0
Aug 31 19:09:29 server kernel: [208104.532097] [<ffffffff810a7db0>] ? prepare_to_wait_event+0xf0/0xf0
Aug 31 19:09:29 server kernel: [208104.532981] [<ffffffff81152690>] ? balance_pgdat+0x5c0/0x5c0
Aug 31 19:09:29 server kernel: [208104.533862] [<ffffffff8108800d>] ? kthread+0xbd/0xe0
Aug 31 19:09:29 server kernel: [208104.534739] [<ffffffff81087f50>] ? kthread_create_on_node+0x180/0x180
Aug 31 19:09:29 server kernel: [208104.535614] [<ffffffff81514158>] ? ret_from_fork+0x58/0x90
Aug 31 19:09:29 server kernel: [208104.536487] [<ffffffff81087f50>] ? kthread_create_on_node+0x180/0x180
Aug 31 19:09:29 server kernel: [208104.537336] Code: 28 8b 4d 10 89 c2 48 0f af d1 0f b6 4d 14 48 c1 ea 20 29 d0 d3 e8 0f b6 4d 15 01 c2 8b 46 18 d3 ea 48 8b 4e 10 83 e8 01 89 46 18 <88> 14 01 49 8b 40 38 48 83 c0 01 49 89 40 38 8b 56 18 85 d2 0f
Aug 31 19:09:29 server kernel: [208104.539120] RIP [<ffffffff8118d344>] free_block+0x124/0x1c0
Aug 31 19:09:29 server kernel: [208104.539995] RSP <ffff88011a197ba8>
Aug 31 19:09:29 server kernel: [208104.540850] CR2: 0000000113382d84
Aug 31 19:09:29 server kernel: [208104.544276] ---[ end trace 337224c62b1d10ca ]---
Aug 31 19:09:50 server kernel: [208117.716620] ------------[ cut here ]------------
Aug 31 19:09:50 server kernel: [208117.716628] WARNING: CPU: 3 PID: 9965 at /build/linux-7z1rSb/linux-3.16.7-ckt25/kernel/watchdog.c:265 watchdog_overflow_callback+0x98/0xc0()
Aug 31 19:09:50 server kernel: [208117.716629] Watchdog detected hard LOCKUP on cpu 3
Aug 31 19:09:50 server kernel: [208117.716630] Modules linked in: dm_crypt dm_mod usb_storage arc4 ecb md4 hmac cfg80211 rfkill nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc nls_utf8 cifs dns_resolver fscache x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic intel_rapl snd_hda_intel snd_hda_controller coretemp snd_soc_rt5640 snd_soc_rl6231 snd_soc_core kvm_intel snd_hda_codec snd_compress snd_hwdep kvm snd_pcm crc32_pclmul snd_timer aesni_intel aes_x86_64 lrw i915 drm_kms_helper snd ppdev evdev pcspkr gf128mul soundcore serio_raw drm glue_helper ablk_helper cryptd i2c_algo_bit regmap_i2c i2c_designware_platform i2c_designware_core mei_me parport_pc shpchp snd_soc_sst_acpi mei parport video battery button processor acpi_pad fuse autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common ahci libahci crc32c_intel libata psmouse scsi_mod ehci_pci ehci_hcd xhci_hcd r8169 mii usbcore usb_common thermal fan thermal_sys sdhci_acpi sdhci mmc_core i2c_hid hid i2c_core
Aug 31 19:09:50 server kernel: [208117.716683] CPU: 3 PID: 9965 Comm: kworker/3:0 Tainted: G D 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 19:09:50 server kernel: [208117.716685] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 19:09:50 server kernel: [208117.716688] Workqueue: events cache_reap
Aug 31 19:09:50 server kernel: [208117.716690] 0000000000000000 ffffffff8150e08f ffff88011fb85c98 0000000000000009
Aug 31 19:09:50 server kernel: [208117.716692] ffffffff81067777 ffff88011a939c00 ffff88011fb85ce8 ffff88011fb85d88
Aug 31 19:09:50 server kernel: [208117.716694] 0000000000000000 ffff88011fb85ef8 ffffffff810677dc ffffffff8171d648
Aug 31 19:09:50 server kernel: [208117.716696] Call Trace:
Aug 31 19:09:50 server kernel: [208117.716697] <NMI> [<ffffffff8150e08f>] ? dump_stack+0x5d/0x78
Aug 31 19:09:50 server kernel: [208117.716705] [<ffffffff81067777>] ? warn_slowpath_common+0x77/0x90
Aug 31 19:09:50 server kernel: [208117.716707] [<ffffffff810677dc>] ? warn_slowpath_fmt+0x4c/0x50
Aug 31 19:09:50 server kernel: [208117.716709] [<ffffffff810fd058>] ? watchdog_overflow_callback+0x98/0xc0
Aug 31 19:09:50 server kernel: [208117.716713] [<ffffffff81134877>] ? __perf_event_overflow+0x87/0x230
Aug 31 19:09:50 server kernel: [208117.716715] [<ffffffff8102f8ba>] ? intel_pmu_handle_irq+0x1ea/0x3d0
Aug 31 19:09:50 server kernel: [208117.716718] [<ffffffff810274c6>] ? perf_event_nmi_handler+0x26/0x40
Aug 31 19:09:50 server kernel: [208117.716720] [<ffffffff8101694d>] ? nmi_handle+0x8d/0x120
Aug 31 19:09:50 server kernel: [208117.716722] [<ffffffff81016e73>] ? default_do_nmi+0x43/0x110
Aug 31 19:09:50 server kernel: [208117.716723] [<ffffffff81017034>] ? do_nmi+0xf4/0x170
Aug 31 19:09:50 server kernel: [208117.716725] [<ffffffff8151660f>] ? end_repeat_nmi+0x1a/0x1e
Aug 31 19:09:50 server kernel: [208117.716728] [<ffffffff81513abc>] ? _raw_spin_lock_irq+0x2c/0x40
Aug 31 19:09:50 server kernel: [208117.716730] [<ffffffff81513abc>] ? _raw_spin_lock_irq+0x2c/0x40
Aug 31 19:09:50 server kernel: [208117.716732] [<ffffffff81513abc>] ? _raw_spin_lock_irq+0x2c/0x40
Aug 31 19:09:50 server kernel: [208117.716733] <<eoe>> [<ffffffff8118d595>] ? drain_array+0x85/0x120
Aug 31 19:09:50 server kernel: [208117.716736] [<ffffffff8118d7d2>] ? cache_reap+0x82/0x230
Aug 31 19:09:50 server kernel: [208117.716738] [<ffffffff81081742>] ? process_one_work+0x172/0x420
Aug 31 19:09:50 server kernel: [208117.716740] [<ffffffff81081dd3>] ? worker_thread+0x113/0x4f0
Aug 31 19:09:50 server kernel: [208117.716742] [<ffffffff815105c1>] ? __schedule+0x2b1/0x700
Aug 31 19:09:50 server kernel: [208117.716743] [<ffffffff81081cc0>] ? rescuer_thread+0x2d0/0x2d0
Aug 31 19:09:50 server kernel: [208117.716746] [<ffffffff8108800d>] ? kthread+0xbd/0xe0
Aug 31 19:09:50 server kernel: [208117.716748] [<ffffffff81087f50>] ? kthread_create_on_node+0x180/0x180
Aug 31 19:09:50 server kernel: [208117.716750] [<ffffffff81514158>] ? ret_from_fork+0x58/0x90
Aug 31 19:09:50 server kernel: [208117.716752] [<ffffffff81087f50>] ? kthread_create_on_node+0x180/0x180
Aug 31 19:09:50 server kernel: [208117.716753] ---[ end trace 337224c62b1d10cb ]---
Aug 31 19:09:50 server kernel: [208121.697108] ------------[ cut here ]------------
Aug 31 19:09:50 server kernel: [208121.697112] WARNING: CPU: 1 PID: 11278 at /build/linux-7z1rSb/linux-3.16.7-ckt25/kernel/watchdog.c:265 watchdog_overflow_callback+0x98/0xc0()
Aug 31 19:09:50 server kernel: [208121.697112] Watchdog detected hard LOCKUP on cpu 1
Aug 31 19:09:50 server kernel: [208121.697113] Modules linked in: dm_crypt dm_mod usb_storage arc4 ecb md4 hmac cfg80211 rfkill nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc nls_utf8 cifs dns_resolver fscache x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic intel_rapl snd_hda_intel snd_hda_controller coretemp snd_soc_rt5640 snd_soc_rl6231 snd_soc_core kvm_intel snd_hda_codec snd_compress snd_hwdep kvm snd_pcm crc32_pclmul snd_timer aesni_intel aes_x86_64 lrw i915 drm_kms_helper snd ppdev evdev pcspkr gf128mul soundcore serio_raw drm glue_helper ablk_helper cryptd i2c_algo_bit regmap_i2c i2c_designware_platform i2c_designware_core mei_me parport_pc shpchp snd_soc_sst_acpi mei parport video battery button processor acpi_pad fuse autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common ahci libahci crc32c_intel libata psmouse scsi_mod ehci_pci ehci_hcd xhci_hcd r8169 mii usbcore usb_common thermal fan thermal_sys sdhci_acpi sdhci mmc_core i2c_hid hid i2c_core
Aug 31 19:09:50 server kernel: [208121.697152] CPU: 1 PID: 11278 Comm: rsync Tainted: G D W 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 19:09:50 server kernel: [208121.697153] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 19:09:50 server kernel: [208121.697153] 0000000000000000 ffffffff8150e08f ffff88011fa85c98 0000000000000009
Aug 31 19:09:50 server kernel: [208121.697155] ffffffff81067777 ffff88011a870c00 ffff88011fa85ce8 ffff88011fa85d88
Aug 31 19:09:50 server kernel: [208121.697157] 0000000000000000 ffff88011fa85ef8 ffffffff810677dc ffffffff8171d648
Aug 31 19:09:50 server kernel: [208121.697159] Call Trace:
Aug 31 19:09:50 server kernel: [208121.697160] <NMI> [<ffffffff8150e08f>] ? dump_stack+0x5d/0x78
Aug 31 19:09:50 server kernel: [208121.697164] [<ffffffff81067777>] ? warn_slowpath_common+0x77/0x90
Aug 31 19:09:50 server kernel: [208121.697166] [<ffffffff810677dc>] ? warn_slowpath_fmt+0x4c/0x50
Aug 31 19:09:50 server kernel: [208121.697168] [<ffffffff810fd058>] ? watchdog_overflow_callback+0x98/0xc0
Aug 31 19:09:50 server kernel: [208121.697170] [<ffffffff81134877>] ? __perf_event_overflow+0x87/0x230
Aug 31 19:09:50 server kernel: [208121.697172] [<ffffffff8102f8ba>] ? intel_pmu_handle_irq+0x1ea/0x3d0
Aug 31 19:09:50 server kernel: [208121.697174] [<ffffffff810274c6>] ? perf_event_nmi_handler+0x26/0x40
Aug 31 19:09:50 server kernel: [208121.697175] [<ffffffff8101694d>] ? nmi_handle+0x8d/0x120
Aug 31 19:09:50 server kernel: [208121.697177] [<ffffffff81016eed>] ? default_do_nmi+0xbd/0x110
Aug 31 19:09:50 server kernel: [208121.697178] [<ffffffff81017034>] ? do_nmi+0xf4/0x170
Aug 31 19:09:50 server kernel: [208121.697180] [<ffffffff8151660f>] ? end_repeat_nmi+0x1a/0x1e
Aug 31 19:09:50 server kernel: [208121.697182] [<ffffffff81513d48>] ? _raw_spin_lock+0x28/0x30
Aug 31 19:09:50 server kernel: [208121.697184] [<ffffffff81513d48>] ? _raw_spin_lock+0x28/0x30
Aug 31 19:09:50 server kernel: [208121.697186] [<ffffffff81513d48>] ? _raw_spin_lock+0x28/0x30
Aug 31 19:09:50 server kernel: [208121.697187] <<eoe>> [<ffffffff8118eff9>] ? kmem_cache_alloc+0x289/0x450
Aug 31 19:09:50 server kernel: [208121.697191] [<ffffffff810a7757>] ? __wake_up_common+0x57/0x90
Aug 31 19:09:50 server kernel: [208121.697196] [<ffffffffa00a2339>] ? mb_cache_entry_alloc+0x109/0x21d [mbcache]
Aug 31 19:09:50 server kernel: [208121.697207] [<ffffffffa0265ece>] ? ext4_xattr_cache_insert+0x1e/0x70 [ext4]
Aug 31 19:09:50 server kernel: [208121.697213] [<ffffffffa0267a6c>] ? ext4_xattr_get+0x20c/0x2a0 [ext4]
Aug 31 19:09:50 server kernel: [208121.697216] [<ffffffff81413a46>] ? skb_copy_datagram_iovec+0x136/0x2a0
Aug 31 19:09:50 server kernel: [208121.697219] [<ffffffff811cad26>] ? generic_getxattr+0x46/0x70
Aug 31 19:09:50 server kernel: [208121.697223] [<ffffffff81232b79>] ? cap_inode_need_killpriv+0x29/0x40
Aug 31 19:09:50 server kernel: [208121.697226] [<ffffffff811c1a63>] ? file_remove_suid+0x43/0xb0
Aug 31 19:09:50 server kernel: [208121.697228] [<ffffffff8113f0d2>] ? __generic_file_write_iter+0x122/0x340
Aug 31 19:09:50 server kernel: [208121.697234] [<ffffffffa0222b10>] ? ext4_file_write_iter+0xf0/0x3a0 [ext4]
Aug 31 19:09:50 server kernel: [208121.697237] [<ffffffff811a7e44>] ? new_sync_write+0x74/0xa0
Aug 31 19:09:50 server kernel: [208121.697239] [<ffffffff811a8582>] ? vfs_write+0xb2/0x1f0
Aug 31 19:09:50 server kernel: [208121.697241] [<ffffffff811a844d>] ? vfs_read+0xed/0x170
Aug 31 19:09:50 server kernel: [208121.697243] [<ffffffff811a90c2>] ? SyS_write+0x42/0xa0
Aug 31 19:09:50 server kernel: [208121.697245] [<ffffffff8151420d>] ? system_call_fast_compare_end+0x10/0x15
Aug 31 19:09:50 server kernel: [208121.697246] ---[ end trace 337224c62b1d10cc ]---
Aug 31 19:09:50 server kernel: [208125.637303] INFO: rcu_sched detected stalls on CPUs/tasks: { 1} (detected by 0, t=5252 jiffies, g=4172818, c=4172817, q=43)
Aug 31 19:09:50 server kernel: [208125.637307] sending NMI to all CPUs:
Aug 31 19:09:50 server kernel: [208125.637309] NMI backtrace for cpu 1
Aug 31 19:09:50 server kernel: [208125.637311] CPU: 1 PID: 11278 Comm: rsync Tainted: G D W 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 19:09:50 server kernel: [208125.637312] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 19:09:50 server kernel: [208125.637313] task: ffff88011a684150 ti: ffff880003440000 task.ti: ffff880003440000
Aug 31 19:09:50 server kernel: [208125.637314] RIP: 0010:[<ffffffff81513d48>] [<ffffffff81513d48>] _raw_spin_lock+0x28/0x30
Aug 31 19:09:50 server kernel: [208125.637317] RSP: 0018:ffff880003443bd0 EFLAGS: 00000097
Aug 31 19:09:50 server kernel: [208125.637318] RAX: 00000000000041a7 RBX: 0000000000000050 RCX: 00000000000041a8
Aug 31 19:09:50 server kernel: [208125.637319] RDX: 00000000000041a8 RSI: 0000000000000000 RDI: ffff880037178540
Aug 31 19:09:50 server kernel: [208125.637320] RBP: ffff880037178540 R08: ffff8800040633d0 R09: 0000000000000000
Aug 31 19:09:50 server kernel: [208125.637321] R10: ffff8800040633d0 R11: 0000000000000246 R12: 000000004a1c4a25
Aug 31 19:09:50 server kernel: [208125.637322] R13: ffff88011a9fc4c0 R14: 000000000000003c R15: ffff88011a91a000
Aug 31 19:09:50 server kernel: [208125.637324] FS: 00007f271ea50700(0000) GS:ffff88011fa80000(0000) knlGS:0000000000000000
Aug 31 19:09:50 server kernel: [208125.637325] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 31 19:09:50 server kernel: [208125.637326] CR2: 00007f271fb1bff0 CR3: 00000000ad40a000 CR4: 00000000001407e0
Aug 31 19:09:50 server kernel: [208125.637327] Stack:
Aug 31 19:09:50 server kernel: [208125.637328] ffffffff8118eff9 0000000000000246 ffffffff810a7757 00000001a026d5e0
Aug 31 19:09:50 server kernel: [208125.637330] 0000000000000050 0000000000000001 ffff8800d2058680 ffff8800040633d0
Aug 31 19:09:50 server kernel: [208125.637332] 000000004a1c4a25 0000000000000006 0000000000000000 00000000ffffffc3
Aug 31 19:09:50 server kernel: [208125.637334] Call Trace:
Aug 31 19:09:50 server kernel: [208125.637336] [<ffffffff8118eff9>] ? kmem_cache_alloc+0x289/0x450
Aug 31 19:09:50 server kernel: [208125.637338] [<ffffffff810a7757>] ? __wake_up_common+0x57/0x90
Aug 31 19:09:50 server kernel: [208125.637342] [<ffffffffa00a2339>] ? mb_cache_entry_alloc+0x109/0x21d [mbcache]
Aug 31 19:09:50 server kernel: [208125.637348] [<ffffffffa0265ece>] ? ext4_xattr_cache_insert+0x1e/0x70 [ext4]
Aug 31 19:09:50 server kernel: [208125.637354] [<ffffffffa0267a6c>] ? ext4_xattr_get+0x20c/0x2a0 [ext4]
Aug 31 19:09:50 server kernel: [208125.637356] [<ffffffff81413a46>] ? skb_copy_datagram_iovec+0x136/0x2a0
Aug 31 19:09:50 server kernel: [208125.637359] [<ffffffff811cad26>] ? generic_getxattr+0x46/0x70
Aug 31 19:09:50 server kernel: [208125.637362] [<ffffffff81232b79>] ? cap_inode_need_killpriv+0x29/0x40
Aug 31 19:09:50 server kernel: [208125.637364] [<ffffffff811c1a63>] ? file_remove_suid+0x43/0xb0
Aug 31 19:09:50 server kernel: [208125.637367] [<ffffffff8113f0d2>] ? __generic_file_write_iter+0x122/0x340
Aug 31 19:09:50 server kernel: [208125.637372] [<ffffffffa0222b10>] ? ext4_file_write_iter+0xf0/0x3a0 [ext4]
Aug 31 19:09:50 server kernel: [208125.637375] [<ffffffff811a7e44>] ? new_sync_write+0x74/0xa0
Aug 31 19:09:50 server kernel: [208125.637377] [<ffffffff811a8582>] ? vfs_write+0xb2/0x1f0
Aug 31 19:09:50 server kernel: [208125.637379] [<ffffffff811a844d>] ? vfs_read+0xed/0x170
Aug 31 19:09:50 server kernel: [208125.637381] [<ffffffff811a90c2>] ? SyS_write+0x42/0xa0
Aug 31 19:09:50 server kernel: [208125.637383] [<ffffffff8151420d>] ? system_call_fast_compare_end+0x10/0x15
Aug 31 19:09:50 server kernel: [208125.637384] Code: 00 00 00 0f 1f 44 00 00 b8 00 00 01 00 f0 0f c1 07 89 c2 c1 ea 10 66 39 c2 89 d1 75 01 c3 0f b7 07 66 39 d0 74 f7 f3 90 0f b7 07 <66> 39 c8 75 f6 c3 66 90 0f 1f 44 00 00 65 81 04 25 60 b8 00 00
Aug 31 19:09:50 server kernel: [208125.637405] NMI backtrace for cpu 3
Aug 31 19:09:50 server kernel: [208125.637407] CPU: 3 PID: 9965 Comm: kworker/3:0 Tainted: G D W 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 19:09:50 server kernel: [208125.637408] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 19:09:50 server kernel: [208125.637409] Workqueue: events cache_reap
Aug 31 19:09:50 server kernel: [208125.637410] task: ffff8800d470b530 ti: ffff880100cf4000 task.ti: ffff880100cf4000
Aug 31 19:09:50 server kernel: [208125.637411] RIP: 0010:[<ffffffff81513abf>] [<ffffffff81513abf>] _raw_spin_lock_irq+0x2f/0x40
Aug 31 19:09:50 server kernel: [208125.637414] RSP: 0018:ffff880100cf7db0 EFLAGS: 00000093
Aug 31 19:09:50 server kernel: [208125.637415] RAX: 00000000000041a7 RBX: ffff8800d1a42800 RCX: 00000000000041a9
Aug 31 19:09:50 server kernel: [208125.637416] RDX: 00000000000041a9 RSI: ffff880037178540 RDI: ffff880037178540
Aug 31 19:09:50 server kernel: [208125.637417] RBP: ffff880037178540 R08: 0000000000000000 R09: dffb091d4db8f480
Aug 31 19:09:50 server kernel: [208125.637418] R10: dffb091d4db8f480 R11: 0000000000000006 R12: 0000000000000000
Aug 31 19:09:50 server kernel: [208125.637419] R13: ffff88011a9fc4c0 R14: 0000000000000000 R15: 0000000000000000
Aug 31 19:09:50 server kernel: [208125.637420] FS: 0000000000000000(0000) GS:ffff88011fb80000(0000) knlGS:0000000000000000
Aug 31 19:09:50 server kernel: [208125.637421] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 31 19:09:50 server kernel: [208125.637422] CR2: 00007f272129319f CR3: 0000000001813000 CR4: 00000000001407e0
Aug 31 19:09:50 server kernel: [208125.637423] Stack:
Aug 31 19:09:50 server kernel: [208125.637424] ffffffff8118d595 0000000000000000 ffff880037178540 ffff88011a9fc4c0
Aug 31 19:09:50 server kernel: [208125.637426] ffff88011fb92700 0000000000000000 0000000000000000 0000000000000000
Aug 31 19:09:50 server kernel: [208125.637427] ffffffff8118d7d2 ffff88011fb8f480 ffff88011fb8f480 ffff880016a1e340
Aug 31 19:09:50 server kernel: [208125.637429] Call Trace:
Aug 31 19:09:50 server kernel: [208125.637431] [<ffffffff8118d595>] ? drain_array+0x85/0x120
Aug 31 19:09:50 server kernel: [208125.637433] [<ffffffff8118d7d2>] ? cache_reap+0x82/0x230
Aug 31 19:09:50 server kernel: [208125.637434] [<ffffffff81081742>] ? process_one_work+0x172/0x420
Aug 31 19:09:50 server kernel: [208125.637436] [<ffffffff81081dd3>] ? worker_thread+0x113/0x4f0
Aug 31 19:09:50 server kernel: [208125.637438] [<ffffffff815105c1>] ? __schedule+0x2b1/0x700
Aug 31 19:09:50 server kernel: [208125.637439] [<ffffffff81081cc0>] ? rescuer_thread+0x2d0/0x2d0
Aug 31 19:09:50 server kernel: [208125.637441] [<ffffffff8108800d>] ? kthread+0xbd/0xe0
Aug 31 19:09:50 server kernel: [208125.637443] [<ffffffff81087f50>] ? kthread_create_on_node+0x180/0x180
Aug 31 19:09:50 server kernel: [208125.637445] [<ffffffff81514158>] ? ret_from_fork+0x58/0x90
Aug 31 19:09:50 server kernel: [208125.637447] [<ffffffff81087f50>] ? kthread_create_on_node+0x180/0x180
Aug 31 19:09:50 server kernel: [208125.637448] Code: 00 fa 66 0f 1f 44 00 00 b8 00 00 01 00 f0 0f c1 07 89 c2 c1 ea 10 66 39 c2 89 d1 75 01 c3 0f b7 07 66 39 d0 74 f7 f3 90 0f b7 07 <66> 39 c8 75 f6 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
Aug 31 21:19:01 server kernel: [215865.042795] NMI backtrace for cpu 0
Aug 31 21:19:01 server kernel: [215865.042798] CPU: 0 PID: 1154 Comm: gnome-shell Tainted: G D W 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 21:19:01 server kernel: [215865.042799] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 21:19:01 server kernel: [215865.042800] task: ffff8800370654f0 ti: ffff880036584000 task.ti: ffff880036584000
Aug 31 21:19:01 server kernel: [215865.042801] RIP: 0010:[<ffffffff812b6a99>] [<ffffffff812b6a99>] __const_udelay+0x9/0x30
Aug 31 21:19:01 server kernel: [215865.042805] RSP: 0018:ffff88011fa03e50 EFLAGS: 00000046
Aug 31 21:19:01 server kernel: [215865.042806] RAX: 0000000000000000 RBX: 0000000000002710 RCX: 0000000000000008
Aug 31 21:19:01 server kernel: [215865.042807] RDX: 0000000000dbb784 RSI: 0000000000000200 RDI: 0000000000418958
Aug 31 21:19:01 server kernel: [215865.042808] RBP: ffffffff81853780 R08: 000000000000000a R09: 00000000000067e1
Aug 31 21:19:01 server kernel: [215865.042809] R10: 0000000000000000 R11: ffff88011fa03b96 R12: 0000000000000000
Aug 31 21:19:01 server kernel: [215865.042811] R13: ffffffff818e2e40 R14: 00000000000037b2 R15: ffffffff81853780
Aug 31 21:19:01 server kernel: [215865.042812] FS: 00007efff75aba40(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000
Aug 31 21:19:01 server kernel: [215865.042813] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 31 21:19:01 server kernel: [215865.042814] CR2: 00007effb26d0000 CR3: 00000000362ea000 CR4: 00000000001407f0
Aug 31 21:19:01 server kernel: [215865.042815] Stack:
Aug 31 21:19:01 server kernel: [215865.042816] ffffffff810469ea ffff88011fa0d660 ffffffff810c5a1d 0000000000000001
Aug 31 21:19:01 server kernel: [215865.042818] 0000000000000083 0000000100000086 ffff8800370654f0 0000000000000000
Aug 31 21:19:01 server kernel: [215865.042820] 0000000000000000 ffff88011fa0d1a0 ffff88011fa03f68 ffffffff810d0200
Aug 31 21:19:01 server kernel: [215865.042822] Call Trace:
Aug 31 21:19:01 server kernel: [215865.042824] <IRQ>
Aug 31 21:19:01 server kernel: [215865.042824] [<ffffffff810469ea>] ? arch_trigger_all_cpu_backtrace+0x10a/0x140
Aug 31 21:19:01 server kernel: [215865.042830] [<ffffffff810c5a1d>] ? rcu_check_callbacks+0x60d/0x630
Aug 31 21:19:01 server kernel: [215865.042833] [<ffffffff810d0200>] ? tick_sched_handle.isra.16+0x60/0x60
Aug 31 21:19:01 server kernel: [215865.042836] [<ffffffff81074b20>] ? update_process_times+0x40/0x70
Aug 31 21:19:01 server kernel: [215865.042838] [<ffffffff810d01c0>] ? tick_sched_handle.isra.16+0x20/0x60
Aug 31 21:19:01 server kernel: [215865.042840] [<ffffffff810d023c>] ? tick_sched_timer+0x3c/0x60
Aug 31 21:19:01 server kernel: [215865.042842] [<ffffffff8108b0f7>] ? __run_hrtimer+0x67/0x1c0
Aug 31 21:19:01 server kernel: [215865.042844] [<ffffffff8108b4a9>] ? hrtimer_interrupt+0xe9/0x220
Aug 31 21:19:01 server kernel: [215865.042847] [<ffffffff8105d510>] ? flush_tlb_func+0xa0/0xa0
Aug 31 21:19:01 server kernel: [215865.042850] [<ffffffff815170eb>] ? smp_apic_timer_interrupt+0x3b/0x60
Aug 31 21:19:01 server kernel: [215865.042852] [<ffffffff8151517d>] ? apic_timer_interrupt+0x6d/0x80
Aug 31 21:19:01 server kernel: [215865.042853] <EOI>
Aug 31 21:19:01 server kernel: [215865.042854] [<ffffffff810d567a>] ? smp_call_function_many+0x20a/0x260
Aug 31 21:19:01 server kernel: [215865.042858] [<ffffffff8105d510>] ? flush_tlb_func+0xa0/0xa0
Aug 31 21:19:01 server kernel: [215865.042860] [<ffffffff810d58a8>] ? on_each_cpu+0x28/0x50
Aug 31 21:19:01 server kernel: [215865.042862] [<ffffffff8105d876>] ? flush_tlb_kernel_range+0x46/0x80
Aug 31 21:19:01 server kernel: [215865.042865] [<ffffffff81175804>] ? __insert_vmap_area+0x74/0xc0
Aug 31 21:19:01 server kernel: [215865.042867] [<ffffffff81175d14>] ? vmap_page_range_noflush+0x274/0x390
Aug 31 21:19:01 server kernel: [215865.042870] [<ffffffff811760e3>] ? __purge_vmap_area_lazy+0x243/0x450
Aug 31 21:19:01 server kernel: [215865.042872] [<ffffffff811764ca>] ? free_vmap_area_noflush+0x5a/0x60
Aug 31 21:19:01 server kernel: [215865.042874] [<ffffffff81177c65>] ? remove_vm_area+0x55/0x70
Aug 31 21:19:01 server kernel: [215865.042876] [<ffffffff81177ca9>] ? __vunmap+0x29/0xf0
Aug 31 21:19:01 server kernel: [215865.042887] [<ffffffffa03f5380>] ? i915_parse_cmds+0x2f0/0x6f0 [i915]
Aug 31 21:19:01 server kernel: [215865.042895] [<ffffffffa03f89c8>] ? i915_gem_do_execbuffer.isra.24+0xcd8/0x13f0 [i915]
Aug 31 21:19:01 server kernel: [215865.042904] [<ffffffffa03ffd38>] ? i915_gem_object_set_to_cpu_domain+0x48/0x180 [i915]
Aug 31 21:19:01 server kernel: [215865.042911] [<ffffffffa03f959f>] ? i915_gem_execbuffer2+0xaf/0x2b0 [i915]
Aug 31 21:19:01 server kernel: [215865.042916] [<ffffffffa03178a7>] ? drm_ioctl+0x1c7/0x5b0 [drm]
Aug 31 21:19:01 server kernel: [215865.042919] [<ffffffff811be12e>] ? dput+0x9e/0x170
Aug 31 21:19:01 server kernel: [215865.042921] [<ffffffff811ba9af>] ? do_vfs_ioctl+0x2cf/0x4b0
Aug 31 21:19:01 server kernel: [215865.042923] [<ffffffff81085261>] ? task_work_run+0x91/0xb0
Aug 31 21:19:01 server kernel: [215865.042924] [<ffffffff811bac11>] ? SyS_ioctl+0x81/0xa0
Aug 31 21:19:01 server kernel: [215865.042927] [<ffffffff8151420d>] ? system_call_fast_compare_end+0x10/0x15
Aug 31 21:19:01 server kernel: [215865.042928] Code: 00 00 48 ff c8 75 fb 48 ff c8 c3 0f 1f 80 00 00 00 00 0f 1f 44 00 00 48 8b 05 2c 37 5e 00 ff e0 66 90 65 48 8b 14 25 a0 26 01 00 <48> 8d 0c 12 48 c1 e2 06 48 8d 04 bd 00 00 00 00 48 29 ca f7 e2
Aug 31 21:19:01 server kernel: [215865.042949] NMI backtrace for cpu 3
Aug 31 21:19:01 server kernel: [215865.042950] CPU: 3 PID: 9965 Comm: kworker/3:0 Tainted: G D W 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 21:19:01 server kernel: [215865.042951] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 21:19:01 server kernel: [215865.042953] Workqueue: events cache_reap
Aug 31 21:19:01 server kernel: [215865.042954] task: ffff8800d470b530 ti: ffff880100cf4000 task.ti: ffff880100cf4000
Aug 31 21:19:01 server kernel: [215865.042955] RIP: 0010:[<ffffffff81513abf>] [<ffffffff81513abf>] _raw_spin_lock_irq+0x2f/0x40
Aug 31 21:19:01 server kernel: [215865.042958] RSP: 0018:ffff880100cf7db0 EFLAGS: 00000093
Aug 31 21:19:01 server kernel: [215865.042959] RAX: 00000000000041a7 RBX: ffff8800d1a42800 RCX: 00000000000041a9
Aug 31 21:19:01 server kernel: [215865.042960] RDX: 00000000000041a9 RSI: ffff880037178540 RDI: ffff880037178540
Aug 31 21:19:01 server kernel: [215865.042961] RBP: ffff880037178540 R08: 0000000000000000 R09: dffb091d4db8f480
Aug 31 21:19:01 server kernel: [215865.042962] R10: dffb091d4db8f480 R11: 0000000000000006 R12: 0000000000000000
Aug 31 21:19:01 server kernel: [215865.042963] R13: ffff88011a9fc4c0 R14: 0000000000000000 R15: 0000000000000000
Aug 31 21:19:01 server kernel: [215865.042964] FS: 0000000000000000(0000) GS:ffff88011fb80000(0000) knlGS:0000000000000000
Aug 31 21:19:01 server kernel: [215865.042965] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 31 21:19:01 server kernel: [215865.042966] CR2: 00007f272129319f CR3: 0000000001813000 CR4: 00000000001407e0
Aug 31 21:19:01 server kernel: [215865.042967] Stack:
Aug 31 21:19:01 server kernel: [215865.042968] ffffffff8118d595 0000000000000000 ffff880037178540 ffff88011a9fc4c0
Aug 31 21:19:01 server kernel: [215865.042969] ffff88011fb92700 0000000000000000 0000000000000000 0000000000000000
Aug 31 21:19:01 server kernel: [215865.042971] ffffffff8118d7d2 ffff88011fb8f480 ffff88011fb8f480 ffff880016a1e340
Aug 31 21:19:01 server kernel: [215865.042973] Call Trace:
Aug 31 21:19:01 server kernel: [215865.042975] [<ffffffff8118d595>] ? drain_array+0x85/0x120
Aug 31 21:19:01 server kernel: [215865.042977] [<ffffffff8118d7d2>] ? cache_reap+0x82/0x230
Aug 31 21:19:01 server kernel: [215865.042978] [<ffffffff81081742>] ? process_one_work+0x172/0x420
Aug 31 21:19:01 server kernel: [215865.042980] [<ffffffff81081dd3>] ? worker_thread+0x113/0x4f0
Aug 31 21:19:01 server kernel: [215865.042982] [<ffffffff815105c1>] ? __schedule+0x2b1/0x700
Aug 31 21:19:01 server kernel: [215865.042983] [<ffffffff81081cc0>] ? rescuer_thread+0x2d0/0x2d0
Aug 31 21:19:01 server kernel: [215865.042985] [<ffffffff8108800d>] ? kthread+0xbd/0xe0
Aug 31 21:19:01 server kernel: [215865.042987] [<ffffffff81087f50>] ? kthread_create_on_node+0x180/0x180
Aug 31 21:19:01 server kernel: [215865.042989] [<ffffffff81514158>] ? ret_from_fork+0x58/0x90
Aug 31 21:19:01 server kernel: [215865.042991] [<ffffffff81087f50>] ? kthread_create_on_node+0x180/0x180
Aug 31 21:19:01 server kernel: [215865.042992] Code: 00 fa 66 0f 1f 44 00 00 b8 00 00 01 00 f0 0f c1 07 89 c2 c1 ea 10 66 39 c2 89 d1 75 01 c3 0f b7 07 66 39 d0 74 f7 f3 90 0f b7 07 <66> 39 c8 75 f6 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00
Aug 31 21:19:01 server kernel: [215865.043012] NMI backtrace for cpu 2
Aug 31 21:19:01 server kernel: [215865.043015] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D W 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 21:19:01 server kernel: [215865.043016] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 21:19:01 server kernel: [215865.043017] task: ffff88011a8100d0 ti: ffff88011a820000 task.ti: ffff88011a820000
Aug 31 21:19:01 server kernel: [215865.043018] RIP: 0010:[<ffffffff8131e012>] [<ffffffff8131e012>] intel_idle+0xc2/0x140
Aug 31 21:19:01 server kernel: [215865.043021] RSP: 0018:ffff88011a823e78 EFLAGS: 00000046
Aug 31 21:19:01 server kernel: [215865.043022] RAX: 0000000000000032 RBX: 0000000000000010 RCX: 0000000000000001
Aug 31 21:19:01 server kernel: [215865.043023] RDX: 0000000000000000 RSI: ffff88011a823fd8 RDI: 0000000000000002
Aug 31 21:19:01 server kernel: [215865.043024] RBP: 0000000000000005 R08: 0000000000000ef4 R09: 0000000000000010
Aug 31 21:19:01 server kernel: [215865.043025] R10: 0000000000002bf2 R11: 0000000000000004 R12: 0000000000000032
Aug 31 21:19:01 server kernel: [215865.043026] R13: 0000000000000004 R14: 0000000000000005 R15: ffffffff8189ea50
Aug 31 21:19:01 server kernel: [215865.043028] FS: 0000000000000000(0000) GS:ffff88011fb00000(0000) knlGS:0000000000000000
Aug 31 21:19:01 server kernel: [215865.043029] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 31 21:19:01 server kernel: [215865.043030] CR2: 00007f5757857000 CR3: 0000000001813000 CR4: 00000000001407e0
Aug 31 21:19:01 server kernel: [215865.043031] Stack:
Aug 31 21:19:01 server kernel: [215865.043031] 000000028101b3f5 ffff88011fb19300 ffff88011a823ed0 ffffffff8189e880
Aug 31 21:19:01 server kernel: [215865.043033] 0000c4a2452828a9 ffffffff813dfaf0 ffffffff818e2e00 ffff88011a820000
Aug 31 21:19:01 server kernel: [215865.043035] ffffffff8189e880 0000000000000005 0000000000000000 ffff88011fb19300
Aug 31 21:19:01 server kernel: [215865.043037] Call Trace:
Aug 31 21:19:01 server kernel: [215865.043040] [<ffffffff813dfaf0>] ? cpuidle_enter_state+0x40/0xc0
Aug 31 21:19:01 server kernel: [215865.043042] [<ffffffff810a82e8>] ? cpu_startup_entry+0x2f8/0x400
Aug 31 21:19:01 server kernel: [215865.043044] [<ffffffff81042c9f>] ? start_secondary+0x20f/0x2d0
Aug 31 21:19:01 server kernel: [215865.043045] Code: 31 d2 65 48 8b 34 25 88 b8 00 00 48 89 d1 48 8d 86 38 c0 ff ff 0f 01 c8 48 8b 86 38 c0 ff ff a8 08 75 08 b1 01 4c 89 e0 0f 01 c9 <65> 48 8b 0c 25 88 b8 00 00 f0 80 a1 3a c0 ff ff df 0f ae f0 48
Aug 31 21:19:28 server kernel: [215891.852927] BUG: soft lockup - CPU#0 stuck for 22s! [gnome-shell:1154]
Aug 31 21:19:28 server kernel: [215891.852929] Modules linked in: dm_crypt dm_mod usb_storage arc4 ecb md4 hmac cfg80211 rfkill nfsd auth_rpcgss oid_registry nfs_acl nfs lockd sunrpc nls_utf8 cifs dns_resolver fscache x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic intel_rapl snd_hda_intel snd_hda_controller coretemp snd_soc_rt5640 snd_soc_rl6231 snd_soc_core kvm_intel snd_hda_codec snd_compress snd_hwdep kvm snd_pcm crc32_pclmul snd_timer aesni_intel aes_x86_64 lrw i915 drm_kms_helper snd ppdev evdev pcspkr gf128mul soundcore serio_raw drm glue_helper ablk_helper cryptd i2c_algo_bit regmap_i2c i2c_designware_platform i2c_designware_core mei_me parport_pc shpchp snd_soc_sst_acpi mei parport video battery button processor acpi_pad fuse autofs4 ext4 crc16 mbcache jbd2 hid_generic usbhid sg sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common ahci libahci crc32c_intel libata psmouse scsi_mod ehci_pci ehci_hcd xhci_hcd r8169 mii usbcore usb_common thermal fan thermal_sys sdhci_acpi sdhci mmc_core i2c_hid hid i2c_core
Aug 31 21:19:28 server kernel: [215891.852961] CPU: 0 PID: 1154 Comm: gnome-shell Tainted: G D W 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
Aug 31 21:19:28 server kernel: [215891.852962] Hardware name: Gigabyte Technology Co., Ltd. Z97-HD3/Z97-HD3, BIOS F4 05/07/2014
Aug 31 21:19:28 server kernel: [215891.852962] task: ffff8800370654f0 ti: ffff880036584000 task.ti: ffff880036584000
Aug 31 21:19:28 server kernel: [215891.852963] RIP: 0010:[<ffffffff810d567e>] [<ffffffff810d567e>] smp_call_function_many+0x20e/0x260
Aug 31 21:19:28 server kernel: [215891.852967] RSP: 0018:ffff880036587ad0 EFLAGS: 00000202
Aug 31 21:19:28 server kernel: [215891.852967] RAX: 0000000000000001 RBX: 000000000000000e RCX: ffff88011fa95de8
Aug 31 21:19:28 server kernel: [215891.852968] RDX: 0000000000000001 RSI: 0000000000000200 RDI: 0000000000000000
Aug 31 21:19:28 server kernel: [215891.852969] RBP: ffff88011fa13a00 R08: ffff88011fa13a08 R09: 0000000000000008
Aug 31 21:19:28 server kernel: [215891.852969] R10: ffff88011fa13a08 R11: 0000000000000007 R12: 0000000000000293
Aug 31 21:19:28 server kernel: [215891.852970] R13: 0000000000000499 R14: 0000000000000000 R15: 0000000000000000
Aug 31 21:19:28 server kernel: [215891.852971] FS: 00007efff75aba40(0000) GS:ffff88011fa00000(0000) knlGS:0000000000000000
Aug 31 21:19:28 server kernel: [215891.852972] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Aug 31 21:19:28 server kernel: [215891.852972] CR2: 00007effb26d0000 CR3: 00000000362ea000 CR4: 00000000001407f0
Aug 31 21:19:28 server kernel: [215891.852973] Stack:
Aug 31 21:19:28 server kernel: [215891.852973] 0000000100000020 0000000000006003 ffffffff8105d510 0000000000000000
Aug 31 21:19:28 server kernel: [215891.852975] ffff880036587bd0 ffffc9001b1e2bf4 ffffc9001b1ea000 ffffffff810d58a8
Aug 31 21:19:28 server kernel: [215891.852976] 0000000000006003 ffff880036587b70 0000000000000000 ffffffff8105d876
Aug 31 21:19:28 server kernel: [215891.852978] Call Trace:
Aug 31 21:19:28 server kernel: [215891.852980] [<ffffffff8105d510>] ? flush_tlb_func+0xa0/0xa0
Aug 31 21:19:28 server kernel: [215891.852982] [<ffffffff810d58a8>] ? on_each_cpu+0x28/0x50
Aug 31 21:19:28 server kernel: [215891.852984] [<ffffffff8105d876>] ? flush_tlb_kernel_range+0x46/0x80
Aug 31 21:19:28 server kernel: [215891.852986] [<ffffffff81175804>] ? __insert_vmap_area+0x74/0xc0
Aug 31 21:19:28 server kernel: [215891.852988] [<ffffffff81175d14>] ? vmap_page_range_noflush+0x274/0x390
Aug 31 21:19:28 server kernel: [215891.852989] [<ffffffff811760e3>] ? __purge_vmap_area_lazy+0x243/0x450
Aug 31 21:19:28 server kernel: [215891.852991] [<ffffffff811764ca>] ? free_vmap_area_noflush+0x5a/0x60
Aug 31 21:19:28 server kernel: [215891.852992] [<ffffffff81177c65>] ? remove_vm_area+0x55/0x70
Aug 31 21:19:28 server kernel: [215891.852994] [<ffffffff81177ca9>] ? __vunmap+0x29/0xf0
Aug 31 21:19:28 server kernel: [215891.853002] [<ffffffffa03f5380>] ? i915_parse_cmds+0x2f0/0x6f0 [i915]
Aug 31 21:19:28 server kernel: [215891.853008] [<ffffffffa03f89c8>] ? i915_gem_do_execbuffer.isra.24+0xcd8/0x13f0 [i915]
Aug 31 21:19:28 server kernel: [215891.853014] [<ffffffffa03ffd38>] ? i915_gem_object_set_to_cpu_domain+0x48/0x180 [i915]
Aug 31 21:19:28 server kernel: [215891.853019] [<ffffffffa03f959f>] ? i915_gem_execbuffer2+0xaf/0x2b0 [i915]
Aug 31 21:19:28 server kernel: [215891.853023] [<ffffffffa03178a7>] ? drm_ioctl+0x1c7/0x5b0 [drm]
Aug 31 21:19:28 server kernel: [215891.853025] [<ffffffff811be12e>] ? dput+0x9e/0x170
Aug 31 21:19:28 server kernel: [215891.853027] [<ffffffff811ba9af>] ? do_vfs_ioctl+0x2cf/0x4b0
Aug 31 21:19:28 server kernel: [215891.853028] [<ffffffff81085261>] ? task_work_run+0x91/0xb0
Aug 31 21:19:28 server kernel: [215891.853029] [<ffffffff811bac11>] ? SyS_ioctl+0x81/0xa0
Aug 31 21:19:28 server kernel: [215891.853031] [<ffffffff8151420d>] ? system_call_fast_compare_end+0x10/0x15
Aug 31 21:19:28 server kernel: [215891.853032] Code: 3b 05 9b e9 80 00 89 c2 0f 8d 7d fe ff ff 48 98 48 8b 4d 00 48 03 0c c5 c0 18 8e 81 f6 41 18 01 74 cb 0f 1f 00 f3 90 f6 41 18 01 <75> f8 eb be 0f b6 4c 24 04 48 83 c4 08 89 ef 5b 5d 4c 89 e6 4c
Sep 1 07:41:32 server kernel: [ 0.000000] Initializing cgroup subsys cpusetDie Leerzeilen am Ende sind mit NULL gefüllt.
Gruß Andreas
Min,
Nochmal die Frage :
Warum nimmst Du nicht statt des Fakeraids das Softwareraid mit den md-devices aus dem linux-kernel? Das läuft wesentlich stabiler als die fakeraids..
lks
Nochmal die Frage :
Warum nimmst Du nicht statt des Fakeraids das Softwareraid mit den md-devices aus dem linux-kernel? Das läuft wesentlich stabiler als die fakeraids..
lks
Tach Gemeinde,
Also generell läuft der Filserver stabil auch wenn das Kopieren der Daten den Filserver zum Absturz bringt. Den Vorgang führen wir nicht durch somit läuft der Filserver.
Backup Zwischenstand:
Nachdem wir den Backupserver zum Testen mit ins Büro genommen haben und Mainbord, Prozessor und RAM getauscht haben lief das Backup übers Wochenende problemlos.
Montag den Server wieder an die alte Stelle gepackt, begannen die gleichen Problem wie vorher.
Also wieder ins Büro gestellt. Mein These es könnten noch Switsch oder Kabel sein lösten sich dann Dienstag in Wohlgefallen auf da auch im Büro die Backups nicht mehr gemacht wurden.
Letzte Nacht wieder Rechner abgestürzt ohne erkennbaren Fehler in den Logs.
Also heute morgen manuell rsync angestoßen
rsync spuckte fleißig Informationen aus bis rsync abgebrochen wurde:
- sender write error broken pipe (10)
- error in socket IO (code 10) at io.c (820)
Ich hatte im Hintergrund ein Fenster von gedit auf das ließ sich daraufhin nicht mehr schließen.
Der Dateibrowser reagierte auch nicht mehr.
Darauf folgte der vollständige Freeze.
Hab daraufhin einen Reset durchgeführt und erstmal die Festplatten geprüft. Alle OK.
Nach dem Neustart hab ich dann erneut den rsync Befehl manuell ausgeführt diesmal ohne Probleme.
Ich werde nun das von dir empfohlene Tool systat installieren und mal gucken ob ich damit fündig werde.
Ich werde euch auf dem Laufenden halten
Gruß Andreas
Also generell läuft der Filserver stabil auch wenn das Kopieren der Daten den Filserver zum Absturz bringt. Den Vorgang führen wir nicht durch somit läuft der Filserver.
Backup Zwischenstand:
Nachdem wir den Backupserver zum Testen mit ins Büro genommen haben und Mainbord, Prozessor und RAM getauscht haben lief das Backup übers Wochenende problemlos.
Montag den Server wieder an die alte Stelle gepackt, begannen die gleichen Problem wie vorher.
Also wieder ins Büro gestellt. Mein These es könnten noch Switsch oder Kabel sein lösten sich dann Dienstag in Wohlgefallen auf da auch im Büro die Backups nicht mehr gemacht wurden.
Letzte Nacht wieder Rechner abgestürzt ohne erkennbaren Fehler in den Logs.
Also heute morgen manuell rsync angestoßen
rsync -aAsv ...- sender write error broken pipe (10)
- error in socket IO (code 10) at io.c (820)
Ich hatte im Hintergrund ein Fenster von gedit auf das ließ sich daraufhin nicht mehr schließen.
Der Dateibrowser reagierte auch nicht mehr.
Darauf folgte der vollständige Freeze.
Hab daraufhin einen Reset durchgeführt und erstmal die Festplatten geprüft. Alle OK.
Nach dem Neustart hab ich dann erneut den rsync Befehl manuell ausgeführt diesmal ohne Probleme.
Ich werde nun das von dir empfohlene Tool systat installieren und mal gucken ob ich damit fündig werde.
Ich werde euch auf dem Laufenden halten
Gruß Andreas
Nachdem ich nun zwei Tage damit verbracht habe dem System beim Sichern zuzusehen und das ganze mit dem Systemmonitor und iotop zu überwachen kam folgendes raus.
Nach ca einer Stunde schnellt eine der CPU auf 100%.
Die Netzwerkübertragung bricht ein.
Datenvolumen ca 220 GB.
Der PC ist nicht mehr zu bedienen.
Werde Montag ein neues System aufsetzen mal schaun was ich nehme ausser Debian und eventuell die neueste Version von rsync.
Soweit der Stand
Schönes Wochenende
Gruß Andreas
Nach ca einer Stunde schnellt eine der CPU auf 100%.
Die Netzwerkübertragung bricht ein.
Datenvolumen ca 220 GB.
Der PC ist nicht mehr zu bedienen.
Werde Montag ein neues System aufsetzen mal schaun was ich nehme ausser Debian und eventuell die neueste Version von rsync.
Soweit der Stand
Schönes Wochenende
Gruß Andreas
Update:
Wir haben das installierte Debian System belassen und im Vorfeld noch weitere Tests durchgeführt.
1. Test: synchronisieren über Cron von einer normalen HDD auf dem Fileserver vollständiger rsync: TEST OK
2. Test: synchronisieren manuell vom Raid vom Fileserver mit ionice -c 3 vollständiger rsync: FEHLGESCHLAGEN
3. Test: synchronisieren manuell vom Raid vom Fileserver mit ionice -c 3 vollständiger rsync jedes Verzeichnis einzeln: TEST OK
4. Test: synchronisieren manuell vom Raid vom Fileserver mit ionice -c 3 inkrementeller rsync: TEST OK
5. Test: synchronisieren über Cron vom Raid vom Fileserver mit ionice -c 3 inkrementeller rsync: TEST OK
Das bringt mich nun zu folgendem Ergebnis für mich. Das Raid spielt bei dem vollständigen Synchronisieren nicht mit. Die Grenze scheint bei ca 200/220 GB in einer Stunde zu liegen.
Meine Lösung daher das Skript löscht den Syncordner im Vorfeld nicht und synchronisiert daher die Daten inkrementell. Das reduziert die Datenmenge auf ein Minimum. Anschließend packe ich das Ganze in ein tar File welches. Somit habe ich für jeden Tag eine Vollsicherung die ich notfalls zurückholen kann.
Wenn ich wegen dem Raid nochmal fündig werde melde ich mich hier wieder.
Gruß Andreas
Wir haben das installierte Debian System belassen und im Vorfeld noch weitere Tests durchgeführt.
1. Test: synchronisieren über Cron von einer normalen HDD auf dem Fileserver vollständiger rsync: TEST OK
2. Test: synchronisieren manuell vom Raid vom Fileserver mit ionice -c 3 vollständiger rsync: FEHLGESCHLAGEN
3. Test: synchronisieren manuell vom Raid vom Fileserver mit ionice -c 3 vollständiger rsync jedes Verzeichnis einzeln: TEST OK
4. Test: synchronisieren manuell vom Raid vom Fileserver mit ionice -c 3 inkrementeller rsync: TEST OK
5. Test: synchronisieren über Cron vom Raid vom Fileserver mit ionice -c 3 inkrementeller rsync: TEST OK
Das bringt mich nun zu folgendem Ergebnis für mich. Das Raid spielt bei dem vollständigen Synchronisieren nicht mit. Die Grenze scheint bei ca 200/220 GB in einer Stunde zu liegen.
Meine Lösung daher das Skript löscht den Syncordner im Vorfeld nicht und synchronisiert daher die Daten inkrementell. Das reduziert die Datenmenge auf ein Minimum. Anschließend packe ich das Ganze in ein tar File welches. Somit habe ich für jeden Tag eine Vollsicherung die ich notfalls zurückholen kann.
Wenn ich wegen dem Raid nochmal fündig werde melde ich mich hier wieder.
Gruß Andreas
