lkml.org 
[lkml]   [2006]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectnfs problems with 2.6.18-rc1
    Hi!

    I recently updated two (old) hosts to 2.6.18-rc1, and started noticing
    weird things with the nfs mounted /home s.

    I frequently face EACCESs where a few minutes ago there wasn't any
    problem, and after a retry everything does work again.

    An example that easily trips it is keeping mutt open
    on a single mailbox file (strace -tt| grep stat):

    20:04:08.393815 stat64("mailbox", {st_mode=S_IFREG|0600, st_size=401000, ...}) = 0
    20:08:41.859168 stat64("mailbox", {st_mode=S_IFREG|0600, st_size=401000, ...}) = 0
    20:09:30.975876 stat64("mailbox", 0xbfe8966c) = -1 EACCES (Permission denied)

    This results in a bit scary "Mailbox was corrupted!" message, but
    otherwise harmless. Reopening the mailbox succeeds immediately.

    A sample session with an rsync session updating files on the nfs mounted
    /home/:

    -----
    > rsync...
    receiving file list ... done
    file1
    rsync: close failed on "/home/path/.file1.UgEmSh": Permission denied (13)
    rsync error: error in file IO (code 11) at receiver.c(628) [receiver]
    rsync: connection unexpectedly closed (2490 bytes received so far) [generator]
    rsync error: error in rsync protocol data stream (code 12) at io.c(471) [generator]
    > rsync...
    receiving file list ... done
    rsync: recv_generator: failed to stat "/home/path/file2": Permission denied (13)
    rsync: recv_generator: failed to stat "/home/path/file3": Permission denied (13)
    rsync: recv_generator: failed to stat "/home/path/file4": Permission denied (13)
    rsync: recv_generator: failed to stat "/home/path/file5": Permission denied (13)
    rsync: recv_generator: failed to stat "/home/path/file6": Permission denied (13)
    rsync: recv_generator: failed to stat "/home/path/file7": Permission denied (13)
    -----

    I also think this is related in the dmesg. Think, because there's no
    other trace of any "read error" on the disks, and the comments in
    mm/filemap.c (but the message is not that much help to be sure of this).

    Reducing readahead size to 28K
    Reducing readahead size to 4K
    Reducing readahead size to 28K
    Reducing readahead size to 4K
    Reducing readahead size to 28K
    Reducing readahead size to 4K
    Reducing readahead size to 0K

    The relevant part of the /proc/mounts file:

    -----
    automount(pid1831) /home autofs rw 0 0
    HOST:/export/PATH /home/path nfs rw,vers=3,rsize=8192,wsize=8192,hard,intr,nolock,proto=udp,timeo=7,retrans=3,sec=sys,addr=HOST 0 0
    -----

    How can I help with tracing this? git bisecting on these machines takes
    at least an hour per step, (and no reasonable connectivity either to
    compile elsewhere much quicker).

    Janos
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-07-13 20:25    [W:2.883 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site