All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steffen Persvold <sp@scali.no>
To: lkml <linux-kernel@vger.kernel.org>,
	nfs list <nfs@lists.sourceforge.net>,
	Neil Brown <neilb@cse.unsw.edu.au>,
	Trond Myklebust <trond.myklebust@fys.uio.no>
Subject: Re: 2.4.8 NFS Problems
Date: Thu, 20 Dec 2001 10:44:45 +0100	[thread overview]
Message-ID: <3C21B30D.871B6BE4@scali.no> (raw)

Hi guys,

I was searching on google for some reports on the problem I'm seeing with our NFS server/clients and
found this thread. It looked somewhat the same (atleast the result with the EIO is the same).

Parts of old message :

>From: Mike Black (mblack@csihq.com)
>Date: Sep 05 2001 

>I've been getting random NFS EIO errors for a few months but
>now it's repeatable. 
>Trying to copy a large file from one 2.4.8 SMP box to another
>is consistently failing (at different offsets >each time). 



Our setup is like this :

Server:
	RedHat 7.2 - kernel 2.4.9-13smp
        nfs-utils-0.3.1-13.7.2.1
	ext3 filesystem (73GB)


Clients:
	ia32 client - RedHat 6.2 - kernel 2.2.19-6.2.7enterprise
	mount-2.10r-0.6.x


	alpha client - RedHat 6.2 - kernel 2.2.19 (vanilla)
	mount-2.10r-5


	ia64 client - RedHat 7.1 - kernel 2.4.3-12smp
	mount-2.10r-5



I've seen the "Input/Output error" problem only on the Alpha and the IA64 clients and the problem is
occuring when making a static library (with 'ar'). The message is like this :

ar: xxxxxx/libmpi.a: Input/output error


The mountpoints is mounted like this :

ia32 client:
huey:/export/home/mpitest /home/mpitest nfs rw,v3,rsize=8192,wsize=8192,addr=huey 0 0

alpha client:
huey:/export/home/mpitest /home/mpitest nfs rw,v3,rsize=8192,wsize=8192,addr=huey 0 0

ia64 client:
huey:/export/home/mpitest /home/mpitest nfs rw,v3,rsize=8192,wsize=8192,hard,udp,lock,addr=huey 0 0


I don't know why the "hard" and "lock" options doesn't appear on ia32 and alpha, but this might be
related to the /proc/mounts interface on the running kernel (these clients are running 2.2.19 while
the ia64 client is running 2.4). The automount entry looks like this :

/home           auto_home       rsize=8192,wsize=8192

So according to the nfs man pages the "hard" option should be default :

       hard           If an NFS file operation has a major timeout then report "server not
                      responding" on the console and continue retrying indefinitely.  This
                      is the default.


So what could be the problem here ? Is it a NFS server bug, a NFS client bug or a NFS/ext3 bug ? We
used to run RedHat 7.0 on this server with the 2.2.19-enterprise kernel, nfs-utils-0.3.1-7 and with
a ext2 filesystem. This problem did not occur back then.

Thanks,
-- 
  Steffen Persvold   | Scalable Linux Systems |   Try out the world's best   
 mailto:sp@scali.no  |  http://www.scali.com  | performing MPI implementation:
Tel: (+47) 2262 8950 |   Olaf Helsets vei 6   |      - ScaMPI 1.12.2 -         
Fax: (+47) 2262 8951 |   N0621 Oslo, NORWAY   | >300MBytes/s and <4uS latency

             reply	other threads:[~2001-12-20  9:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-20  9:44 Steffen Persvold [this message]
2001-12-20 11:10 ` 2.4.8 NFS Problems Trond Myklebust
2001-12-20 14:40   ` Steffen Persvold
2001-12-20 20:27     ` Trond Myklebust
  -- strict thread matches above, loose matches on Subject: below --
2001-09-05 11:56 Mike Black
2001-09-07 11:49 ` Trond Myklebust
2001-09-07 12:05   ` Peter T. Breuer
2001-09-07 12:27     ` Trond Myklebust
2001-09-07 12:36     ` Trond Myklebust
2001-09-07 13:13   ` Mike Black
2001-09-07 14:42     ` Trond Myklebust
2001-09-07 15:46       ` Mike Black
2001-09-08 10:53         ` Trond Myklebust
2001-09-08 11:53           ` Mike Black

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C21B30D.871B6BE4@scali.no \
    --to=sp@scali.no \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@cse.unsw.edu.au \
    --cc=nfs@lists.sourceforge.net \
    --cc=trond.myklebust@fys.uio.no \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.