nfs kernel server works fine, crashes system during usage

1. offizieller Beitrag

    Hi, I have a strange problems with the nfs kernel server, where the machine becomes unresponsive very fast if nfs is used (if nfs is not used for transfers, everything will be fine, cifs works, too.


    my configuration:
    HP N54L, omv 0.5.14, backport 3.2 kernel

    Code
    # /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
/media/shares 192.168.1.0/24(rw,crossmnt)


    to test the nfs kernel server i mount this share on the same machine, and try to write to it via dd:


    Code
    /root/test$ dd if=/dev/zero of=test.img bs=1M count=1048
1048+0 records in
1048+0 records out
1098907648 bytes (1.1 GB) copied, 13.6275 s, 80.6 MB/s
jan@nas:/root/test$ dd if=/dev/zero of=test.img bs=1M count=1048
^C^C^C^CKilled


    mostly speed is fine during the first run, but the second will have to be killed because iowait rockets up to 99%, and the command never finishes. Sometimes the system will even get to busy to recognize shutdown events via power button presses...


    dmesg shows some pretty scary messages: Any Ideas?


    • Offizieller Beitrag

    It is a segfault. Hard to say what is causing it. Could be the network driver?

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    Are you sure your drive is still in good shape?


    Greetings
    David

    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"


    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!

    • Offizieller Beitrag

    Could be but I use nfs for large files all the time without lockups/segfaults and I am using the backports kernel.

    omv 7.1.0-2 sandworm | 64 bit | 6.8 proxmox kernel

    plugins :: omvextrasorg 7.0 | kvm 7.0.13 | compose 7.2 | k8s 7.1.0-3 | cputemp 7.0.1 | mergerfs 7.0.5 | scripts 7.0.7


    omv-extras.org plugins source code and issue tracker - github - changelogs


    Please try ctrl-shift-R and read this before posting a question.

    Please put your OMV system details in your signature.
    Please don't PM for support... Too many PMs!

    No problems with nfs over here, too. Use it for my pi so only large files. Also running backports kernel.


    Greetings
    David

    "Well... lately this forum has become support for everything except omv" [...] "And is like someone is banning Google from their browsers"


    Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.

    Upload Logfile via WebGUI/CLI
    #openmediavault on freenode IRC | German & English | GMT+1
    Absolutely no Support via PM!

    I think it is a kernel bug. The lock up problem is gone using the older kernel. I can repeatedly write to the share without any slowing down of the transfers. Their speed will always be around 55MB/s.


    Code
    jan@nas:/root/test$ uname -a
Linux nas 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64 GNU/Linux


    Code
    jan@nas:/root/test$ dd if=/dev/zero of=test.img bs=1M count=10480
10480+0 records in
10480+0 records out
10989076480 bytes (11 GB) copied, 200.667 s, 54.8 MB/s


    performance is lacking though: cifs is quite a bit faster:


    Code
    root@nas:~/cifs# dd if=/dev/zero of=test.img bs=1M count=10480
10480+0 records in
10480+0 records out
10989076480 bytes (11 GB) copied, 140.191 s, 78.4 MB/s

    back on

    Code
    Linux nas 3.2.0-0.bpo.4-amd64 #1 SMP Debian 3.2.46-1+deb7u1~bpo60+1 x86_64 GNU/Linux


    cifs is working fine:


    Code
    root@nas:~/cifs# dd if=/dev/zero of=test.img bs=1M count=10480
10480+0 records in
10480+0 records out
10989076480 bytes (11 GB) copied, 99.9157 s, 110 MB/s


    the nfs transfer has to be killed on the second run, which takes quite a while:


    Code
    jan@nas:/root/test$  dd if=/dev/zero of=test.img bs=1M count=1048
1048+0 records in
1048+0 records out
1098907648 bytes (1.1 GB) copied, 11.6503 s, 94.3 MB/s
jan@nas:/root/test$  dd if=/dev/zero of=test.img bs=1M count=1048
^C^C^C^C^C^C


    this is iotop during the second try of 1GB:


    Code
    4094 be/4 jan         0.00 B/s    0.00 B/s  0.00 % 99.66 % dd if=/de~count=1048
 1655 be/4 root        0.00 B/s    0.00 B/s  0.00 % 24.43 % [flush-253:0]
 1388 be/3 root        0.00 B/s  117.29 K/s  0.00 % 18.53 % [jbd2/dm-0-8]
 1914 be/4 root        0.00 B/s   31.28 K/s  0.00 % 15.73 % [nfsd]
 1909 be/4 root        0.00 B/s   31.28 K/s  0.00 % 12.12 % [nfsd]
 1912 be/4 root        0.00 B/s   31.28 K/s  0.00 % 12.08 % [nfsd]
 1910 be/4 root        0.00 B/s   31.28 K/s  0.00 % 11.84 % [nfsd]
 1907 be/4 root        0.00 B/s   19.55 K/s  0.00 %  9.34 % [nfsd]
 1905 be/4 root        0.00 B/s    3.91 K/s  0.00 %  1.38 % [nfsd]

    my problem seems to also be fixed in 3.10.1. Thats good enough i think:


    Code
    uname -a
Linux nas 3.10.1-031001-generic #201307131550 SMP Sat Jul 13 19:51:31 UTC 2013 x86_64 GNU/Linux


    Code
    $  dd if=/dev/zero of=test.img bs=1M count=10480
10480+0 records in
10480+0 records out
10989076480 bytes (11 GB) copied, 119.166 s, 92.2 MB/s


    for comparison cifs still performs better:


    Code
    # dd if=/dev/zero of=test.img bs=1M count=10480
10480+0 records in
10480+0 records out
10989076480 bytes (11 GB) copied, 99.2148 s, 111 MB/s

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden