nfsd 100% IO-Wait

KGundermann

Benutzer
Mitglied seit
30. Jun 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Wir haben hier mehrere DS1817+ (DSM 6.2.2-24922) deren Volumes wir über NFS freigeben.

Seit zwei Wochen haben wir Probleme beim NFS Zugriff auf ein NAS, die Clients bleiben beim zugriff einfach hängen.
Auf dem NAS selber sehe ich mit iostat, dass die nfsd Prozesse mit 100% IO-Wait hängen.
Ich kann aber weder die nfsd Prozesse beenden noch kann ich das NAS herunterfahren.
Ein hartes ausschalten des NAS führte nach dem Neustart erst einmal dazu, daß das Sytem drei Tage damit beschäftigt war, das Raid-5 (btrfs) zu überprüfen,
und war trotzdem nicht zu benutzen, da die nfsd Prozesse hängen.

Seit gestern zeigt jetzt das nächste NAS genau das selbe Phänomen....
 

Puppetmaster

Benutzer
Mitglied seit
03. Feb 2012
Beiträge
18.394
Punkte für Reaktionen
365
Punkte
459
Ich nehme einmal an, die Frage soll lauten, worin die Ursache liegen könnte?

Hast du dir auf den betroffenen Maschinen schon einmal die laufenden Prozesse angeschaut? Auffälligkeiten?

Auch die SMART Werte der Festplatten würde ich mir in dem Fall einmal ansehen.
 

KGundermann

Benutzer
Mitglied seit
30. Jun 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Auffälligkeiten der laufenden Prozesse:
- 130 nfsd Prozesse im Status D uninterruptible sleep (usually IO)

> ps - eFl
5 D root 13161 2 0 80 0 - 0 sync_r 0 2 Jun05 ? 00:00:11 [nfsd]
.....

SMART Werte der Festplatten sind ok
 

KGundermann

Benutzer
Mitglied seit
30. Jun 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Der Synology Support ist auch nicht besonders hilfreich:
Das Ticket ist jetzt seit 20 Tage offen, der Supporter hat einmal kurz aufs System geschaut und nur gesagt, ich soll das NAS einmal neu starten.
Er hat also gar nicht richtig verstanden, das sich das NAS nicht herunterfahren lässt...

Ich habe also hier ein NAS, das seit 3 Wochen nicht nutzbar ist ....
 

Puppetmaster

Benutzer
Mitglied seit
03. Feb 2012
Beiträge
18.394
Punkte für Reaktionen
365
Punkte
459
Ja, traurig.

Könnte mir noch vorstellen, dass es am noch nicht ausgereiften BTRFS liegt. Ich meine, sowas hier auch schon einmal gelesen zu haben.

Anonsten kommen für mich nur Platten mit Problemen in Betracht. Also auch (SMART)Fehler, die der Hersteller noch nicht für kritisch hält.
 

KGundermann

Benutzer
Mitglied seit
30. Jun 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Jetzt haben wir das zweite System, das mit dem gleichen Symptom hängt: kein Zugriff über NFS möglich.

Fehlermeldung dmesg:

[2932241.914278] INFO: task nfsd:7016 blocked for more than 120 seconds.
[2932241.921486] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[2932241.930446] nfsd D ffff88027fc12040 0 7016 2 0x00000000
[2932241.938593] ffff88023b7df970 0000000000000046 000000000000c000 ffff88023b7dffd8
[2932241.947093] ffff88023b7dffd8 ffff88023195d040 ffff88023b7dffd8 0000000000000000
[2932241.955589] ffff880275359040 ffff8801703de2b8 ffff8801703de2bc 00000000ffffffff
[2932241.964093] Call Trace:
[2932241.967033] [<ffffffff814b0b44>] ? schedule_preempt_disabled+0x24/0x60
[2932241.974634] [<ffffffff814aec49>] ? __mutex_lock_slowpath+0x129/0x1e0
[2932241.982039] [<ffffffff814ade6e>] ? mutex_lock+0xe/0x20
[2932241.988105] [<ffffffffa0709b4c>] ? btrfs_file_aio_write+0x8c/0x590 [btrfs]
[2932241.996100] [<ffffffff81067dfc>] ? update_group_power+0x1c/0x240
[2932242.003119] [<ffffffff8127a64d>] ? cpumask_next_and+0x2d/0x40
[2932242.009845] [<ffffffff810fd083>] ? do_sync_readv_writev+0x53/0x80
[2932242.016957] [<ffffffff810ff399>] ? do_readv_writev+0xb9/0x480
[2932242.023701] [<ffffffffa0709ac0>] ? btrfs_sync_file+0x330/0x330 [btrfs]
[2932242.031305] [<ffffffff810fcf90>] ? do_sync_read+0xa0/0xa0
[2932242.037639] [<ffffffff8111cb36>] ? d_obtain_alias+0x46/0x1a0
[2932242.044278] [<ffffffffa0732d35>] ? btrfs_get_dentry+0xf5/0x120 [btrfs]
[2932242.051885] [<ffffffffa0d21fc0>] ? _fh_update.isra.10+0x80/0x80 [nfsd]
[2932242.059484] [<ffffffffa0d1a6de>] ? exportfs_decode_fh+0x7e/0x31f [exportfs]
[2932242.067582] [<ffffffffa0d23524>] ? nfsd_vfs_write.isra.16+0x84/0x5b0 [nfsd]
[2932242.075682] [<ffffffffa0d3e18d>] ? find_client_in_id_table+0x12d/0x180 [nfsd]
[2932242.083970] [<ffffffffa0d3e220>] ? lookup_clientid+0x40/0x60 [nfsd]
[2932242.091285] [<ffffffffa0d3d273>] ? find_stateid_by_type+0x23/0x60 [nfsd]
[2932242.099085] [<ffffffffa0d26511>] ? nfsd_permission+0x2a1/0x3e0 [nfsd]
[2932242.106594] [<ffffffffa0d27c86>] ? nfsd_write+0x86/0x110 [nfsd]
[2932242.113517] [<ffffffffa0d32ea8>] ? nfsd4_write+0x1c8/0x260 [nfsd]
[2932242.120638] [<ffffffffa0d322c5>] ? nfsd4_proc_compound+0x665/0x8c0 [nfsd]
[2932242.128535] [<ffffffffa0d1ec35>] ? nfsd_dispatch+0xc5/0x260 [nfsd]
[2932242.135747] [<ffffffff814840af>] ? svc_process+0x5bf/0x860
[2932242.142187] [<ffffffffa0d1e61f>] ? nfsd+0xaf/0x120 [nfsd]
[2932242.148529] [<ffffffffa0d1e570>] ? nfsd_destroy+0x70/0x70 [nfsd]
[2932242.155545] [<ffffffff81053bd2>] ? kthread+0xb2/0xc0
[2932242.161393] [<ffffffff81050000>] ? thaw_workqueues+0x110/0x120
[2932242.168204] [<ffffffff81053b20>] ? kthread_create_on_node+0x110/0x110
[2932242.175704] [<ffffffff814b2c0d>] ? ret_from_fork+0x5d/0xb0
[2932242.182136] [<ffffffff81053b20>] ? kthread_create_on_node+0x110/0x110



Reaktionen vom Synology-Support: Keine ( Ticket ist seit 21 Tagen offen )

Ich habe die Vermutung, das sich Synology nicht als NFS-Server eignet..
 

KGundermann

Benutzer
Mitglied seit
30. Jun 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Könnte es sein, das btrfs auf Synology ein Problem bei hoher IO-Last hat ??

[2932241.988105] [<ffffffffa0709b4c>] ? btrfs_file_aio_write+0x8c/0x590 [btrfs]
 

KGundermann

Benutzer
Mitglied seit
30. Jun 2019
Beiträge
20
Punkte für Reaktionen
0
Punkte
0
Wir haben zwei Systeme auf DSM 6.2.2-24922 Update 2 aktualisert, hat aber leider nichts geholfen,
das Systenm ist beim Backup in der letzten Nacht wieder hängengeblieben und ich konnte heute morgen nur den Stromstecker ziehen..
 

nazgul77

Benutzer
Mitglied seit
01. Jul 2018
Beiträge
7
Punkte für Reaktionen
0
Punkte
0
schaut für mich nach einem korrupten btrfs-Dateisystem oder Fehler im btrfs-Treiber aus. Ein Schreibauftrag hängt im btrfs-Treiber. es sperrt sich exklusiven Zugriff auf interne Datenstrukturen und hängt dann.
Das erklärt auch, warum der kernel das Dateisystem beim Runterfahren nicht sauber aushängen kann und dann selber hängt.