From: "Matt Heaton" Subject: XFS for NFS Date: Fri, 2 Aug 2002 18:43:42 -0600 Sender: nfs-admin@lists.sourceforge.net Message-ID: <041e01c23a86$d0f3c320$6701a8c0@c1886657a> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_041B_01C23A54.862264A0" Return-path: Received: from rwcrmhc52.attbi.com ([216.148.227.88]) by usw-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 17an1K-0005Lb-00 for ; Fri, 02 Aug 2002 17:43:50 -0700 Received: from c1886657a ([12.255.25.93]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020803004344.CXBL22139.rwcrmhc52.attbi.com@c1886657a> for ; Sat, 3 Aug 2002 00:43:44 +0000 To: Errors-To: nfs-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Id: Discussion of NFS under Linux development, interoperability, and testing. List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_041B_01C23A54.862264A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A while the following post was made about XFS and that the problem was = fixed in the 2.4.19 tree of the kernel. My question is do I have to use 2.4.19rc5 on the server or the client or = both to fix the problem. Also is the 1.x version of nfs utils for the client or server or both? Thanks, Matt >We have noticed a problem with a couple of our NFS servers (running >RedHat 7.2 with a stock 2.4.18 kernel with XFS v1.1) whereby NFS access >slows to a crawl or stalls. > >The exported filesystem(s) are XFS with 8 nfsd's running - when we have >the problem the load average is about 8 - but CPU usage, disk access = and >network traffic are minimal. > >I found, by accident, that running the command 'sync' appears to 'fix' >the situation... > >I'm not sure if this is an XFS or NFS related problem (hence posting to >both lists). XFS. 2.4.18 would sometimes get into a situation where two XFS operations were waiting on locks (not deadlocked) and nothing was moving. Performing some other disk activity such as sync would get things moving again. AFAICT this is fixed in the XFS CVS tree, against 2.4.19-rc1. ------=_NextPart_000_041B_01C23A54.862264A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
A while the following post was made = about XFS and=20 that the problem was fixed in the 2.4.19 tree of the = kernel.
My question is do I have to use = 2.4.19rc5 on the=20 server or the client or both to fix the problem.  Also is the 1.x=20 version
of nfs utils for the client or server = or=20 both?
 
Thanks,
Matt
 
 
 

>We have noticed a problem with a couple of our NFS servers=20 (running
>RedHat 7.2 with a stock 2.4.18 kernel with XFS v1.1) = whereby NFS=20 access
>slows to a crawl or stalls.
>
>The exported=20 filesystem(s) are XFS with 8 nfsd's running - when we have
>the = problem=20 the load average is about 8 - but CPU usage, disk access = and
>network=20 traffic are minimal.
>
>I found, by accident, that running = the=20 command 'sync' appears to 'fix'
>the = situation...
>
>I'm not=20 sure if this is an XFS or NFS related problem (hence posting = to
>both=20 lists).

XFS.  2.4.18 would sometimes get into a situation = where two=20 XFS
operations were waiting on locks (not deadlocked) and nothing=20 was
moving.  Performing some other disk activity such as sync = would=20 get
things moving again.

AFAICT this is fixed in the XFS CVS = tree,=20 against 2.4.19-rc1.
------=_NextPart_000_041B_01C23A54.862264A0-- ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ NFS maillist - NFS@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs