Bug 117121
Summary: | performance problem file transfer nfs to nfs/system unusable | ||
---|---|---|---|
Product: | File System | Reporter: | Dieter Ferdinand (dieter.ferdinand) |
Component: | ext3 | Assignee: | Trond Myklebust (trondmy) |
Status: | NEW --- | ||
Severity: | normal | CC: | bfields |
Priority: | P1 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 4.9.xx | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
kernel config for kernel 4.9.22 with the bug
kernel config for kernel 4.9.35 with the bug kernel config for kernel 4.9.23 without the bug |
Description
Dieter Ferdinand
2016-04-24 17:21:19 UTC
So you've seen similar problems on both NFS and CIFS? That and the fact that it recovers after sync might suggest some sort of problem with generic writeback logic. Wonder if it would be worth fooling with vm parameters (e.g., dirty_bytes, dirty_background_bytes?) hello, first time, i have this problem, i reboot my server. at this time i have a second problem with cifs. the cifs-server (nas) have crashed and i must reboot it. after that, all processes which have accessed this mount can't be killed and i can't umount this connection to mount it again. this problem was the reason, why automount don't work because a mount-command hangs. this and the very slow reaction of the server are the reasons to reboot my server. after reboot, i used nfs instead of cifs to access my nas because with hanging nfs-mount, i know how i can resolve this problem without reboot. i restart the data-sync with rsync (or mc) again and after some time, my system gets very slow again, so i try to find a reason for this. symtoms: very slow hd-access and write-rate less then 3 MByte/s. i don't test read-speed alone. i use a tool to protocol hd-transferrate and use unrar or unzip to extract a archive. normaly, i get over 20 MB/s for this. but at this time, very very slow. my tool show also the dirty buffers for the hd, but there are no dirty buffers at this time. with this tool i have detected harddisk-problems while one of my drives was slow down and must be replaced. in this case, the dirty buffers are over 100 for some time. because i have some problems in the past with write-back-caches (most time with windows, but also with dos, if much data is written), i stop my data-synchronisation and run sync, i think, it runs over 60s. i don't stop it. after that, my system ist fast again and i run the data-sync on a system, which is used for backup primery, so it makes no problem, when the system slow down for the synchronisation time. i can't get more information to you and i don't have a second system with 16 GB ram to make more tests and i can't use this system for tests. last time, i update my kernel, a new bug in the xfs-filesystem crash my system over five time in a week, so i must repair my filesystems more than one time and reboot it with the kernel, which i used before i update the system over one year without problems. i think, that this problem don't happens on systems with less ram, because on my second linux-server with kernel 2.6.x i have no problems after i start the data-synchronisation. goodby hello, it seems, that this bug only aktiv, if i copy from nfs-mount to nfs-mount. if i copy from hd to nfs-mount, i have no problems. goodby hello, i must correct me. if i copy from hd to nfs, the system ist slow, if there are some other processes, which transfer much data. but i don't know, which of two action makes the system slow. copy from hd to hd or from netzwork (cifs) to hd. goodby Created attachment 257235 [details]
kernel config for kernel 4.9.22 with the bug
Created attachment 257237 [details]
kernel config for kernel 4.9.35 with the bug
Created attachment 257239 [details]
kernel config for kernel 4.9.23 without the bug
|