From: "Wendy Cheng" Subject: Re: the inode semaphore Date: Wed, 12 Feb 2003 13:45:55 -0500 Sender: nfs-admin@lists.sourceforge.net Message-ID: <00ee01c2d2c6$fa2ebdc0$c5e31a42@tamarac> Reply-To: "Wendy Cheng" Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01C2D29D.11159240" Return-path: Received: from [66.105.142.2] (helo=falconstorex.falconstor.com) by sc8-sf-list1.sourceforge.net with esmtp (Exim 3.31-VA-mm2 #1 (Debian)) id 18j1tw-0000tj-00 for ; Wed, 12 Feb 2003 10:46:32 -0800 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_00EB_01C2D29D.11159240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Adding fh_put() to release the semaphore after nfsd_unlink() within nfs3proc.c does make the hang disappear. Hope we can see this get fixed in the future code. wendy ----- Original Message -----=20 From: Wendy Cheng=20 To: nfs@lists.sourceforge.net=20 Sent: Tuesday, February 11, 2003 12:17 PM Subject: the inode semaphore We're working on a high availability experiment project for our linux-based server and the nfsds hang=20 from times to times. It is observed that the version 3=20 procedure 12/13 (rmdir and remove) obtains an inode=20 semaphore within fh_lock()/nfsd_unlink() but never=20 releases it. Theoretically this inode is going to get=20 released but what can prevent the following two cases=20 that would end up hanging the nfsd ? 1. Due to slow network and/or system, the client re- sends the same request but using a different xid. The=20 nfsd that accepts the new request would be stuck in=20 nfsd_unlink() waiting for the inode semaphore.=20 2. A "create" immediately follows the "remove" for the=20 same file.=20 There is a flag called fh_locked but it is passed in=20 from each individual nfs request (a local copy, not=20 from dcache) that doesn't help. I also browse thru=20 some file system's (say ext3) inode free code but=20 can't find anywhere this semaphore gets released.=20 We're still debugging our failover logic but if=20 someone could confirm the above are indeed a bug (or=20 explain why it will not happen) would be of great=20 helps. Or should this semaphore get "zero"ed out by file=20 system (say, ext3) ?=20 We're on 2.4.19 kernel. Thanks for the help. Wendy ------=_NextPart_000_00EB_01C2D29D.11159240 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1"
Adding fh_put() to release the = semaphore=20 after
nfsd_unlink() within nfs3proc.c = does make the
hang disappear. Hope we can see = this get=20 fixed
in the future code.
 
wendy
----- Original Message -----
From:=20 Wendy Cheng
Sent: Tuesday, February 11, = 2003 12:17=20 PM
Subject: the inode = semaphore

We=92re working on a high = availability=20 experiment
project for our linux-based server and the nfsds hang =
from=20 times to times. It is observed that the version 3
procedure 12/13 = (rmdir=20 and remove) obtains an inode
semaphore within = fh_lock()/nfsd_unlink() but=20 never
releases it. Theoretically this inode is going to get =
released=20 but what can prevent the following two cases
that would end up = hanging the=20 nfsd ?
 
1. Due to slow network and/or system, = the client=20 re-
sends the same request but using a different xid. The
nfsd = that=20 accepts the new request would be stuck in
nfsd_unlink() waiting = for the=20 inode semaphore.
2. A =93create=94 immediately follows the = =93remove=94 for the=20
same file.
 
There is a flag called fh_locked but = it is passed=20 in
from each individual nfs request (a local copy, not
from = dcache)=20 that doesn=92t help. I also browse thru
some file system=92s (say = ext3) inode=20 free code but
can=92t find anywhere this semaphore gets released. =
We=92re=20 still debugging our failover logic but if
someone could confirm = the above=20 are indeed a bug (or
explain why it will not happen) would be of = great=20
helps.
 
Or should this semaphore get = =93zero=94ed out by file=20
system (say, ext3) ?
 
We=92re on 2.4.19 = kernel.
 
Thanks for the help.
 
Wendy
------=_NextPart_000_00EB_01C2D29D.11159240-- ------------------------------------------------------- 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