Bug 195449
| Summary: | Client system gets spammed with 'NFSv4 Callback' kthreads - eventually causing NFS shares to become unresponsive | ||
|---|---|---|---|
| Product: | File System | Reporter: | taijian |
| Component: | NFS | Assignee: | Trond Myklebust (trondmy) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | olaf |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.11-rc7 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
fstab excerpt with nfs mounts
output of lshw config of kernel in (compresed gzip ) |
||
Created attachment 257205 [details]
output of lshw
I have the same problem with vanilla kernel 4.11.6, also I can confirm this bug is present in 4.11.5 I use automount and after some days the machine have about 1,000 kthreads all saying "NFSv4 callback". This computer is monitored via Nagios and I have to restart this machine to stop receiving notifications from Nagios about the high number of processes. Main use of the pc with problems is Kodi, playing media from NFS shares. Created attachment 257209 [details]
config of kernel in (compresed gzip )
Configuration of the kernel for this machine (4.11.6)
Known issue, and fixed in 4.12-rc1. |
Created attachment 255911 [details] fstab excerpt with nfs mounts System: i7-7700HQ Laptop with Kernel 4.11-rc7 (via Arch Linux AUR package linux-mainline, default config) as NFS client. Synology Diskstation DS414 with Synology DSM 6.1 (latest release) as NFS server on local network. Setup: The client computer accesses several nfs shares from the server via fstab entries (see attachment). systemd version 232 for the automount. Problem: The client is getting spammed with 'NFSv4 Callback' kernel threads (at a rate of ~400 new threads per hour). These threads just add up, never go away, do not seem to use CPU time or Memory, but just sit there, sleeping. They do cause the nfs shares to become unresponsive over time, though, so that files no longer open - browsing the file system still works, however. This problem does not occur on either kernel 4.10.10 or 4.9.22. I am perfectly willing to supply additional logs/information, but would unfortunately require directions as to what is needed and how to extract that information.