Linux NFS development
 help / color / mirror / Atom feed
From: "Wendy Cheng" <wendy.cheng@falconstor.com>
To: <nfs@lists.sourceforge.net>
Subject: Re: the inode semaphore
Date: Wed, 12 Feb 2003 13:45:55 -0500	[thread overview]
Message-ID: <00ee01c2d2c6$fa2ebdc0$c5e31a42@tamarac> (raw)

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

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 ----- 
  From: Wendy Cheng 
  To: nfs@lists.sourceforge.net 
  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 
  from times to times. It is observed that the version 3 
  procedure 12/13 (rmdir and remove) obtains an inode 
  semaphore within fh_lock()/nfsd_unlink() but never 
  releases it. Theoretically this inode is going to get 
  released but what can prevent the following two cases 
  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 
  nfsd that accepts the new request would be stuck in 
  nfsd_unlink() waiting for the inode semaphore. 
  2. A "create" immediately follows the "remove" for the 
  same file. 

  There is a flag called fh_locked but it is passed in 
  from each individual nfs request (a local copy, not 
  from dcache) that doesn't help. I also browse thru 
  some file system's (say ext3) inode free code but 
  can't find anywhere this semaphore gets released. 
  We're still debugging our failover logic but if 
  someone could confirm the above are indeed a bug (or 
  explain why it will not happen) would be of great 
  helps.

  Or should this semaphore get "zero"ed out by file 
  system (say, ext3) ? 

  We're on 2.4.19 kernel.

  Thanks for the help.

  Wendy

[-- Attachment #2: Type: text/html, Size: 3322 bytes --]

             reply	other threads:[~2003-02-12 18:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-02-12 18:45 Wendy Cheng [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-02-11 17:17 the inode semaphore Wendy Cheng

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='00ee01c2d2c6$fa2ebdc0$c5e31a42@tamarac' \
    --to=wendy.cheng@falconstor.com \
    --cc=nfs@lists.sourceforge.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox