linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: Namjae Jeon <linkinjeon@gmail.com>,
	"J. Bruce Fields" <bfields@fieldses.org>
Cc: "Trond.Myklebust@netapp.com" <Trond.Myklebust@netapp.com>,
	Amit Sahrawat <a.sahrawat@samsung.com>,
	"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	Namjae Jeon <namjae.jeon@samsung.com>
Subject: Re: [Problem]NFS Server – Umount results in Device Busy.
Date: Thu, 7 Jun 2012 11:13:04 +0300	[thread overview]
Message-ID: <4FD06290.7050004@panasas.com> (raw)
In-Reply-To: <CAKYAXd-HCfcejT=kG-kSXWCmfmxTjrT2o+b3Zan+BCrS1Y2ovw@mail.gmail.com>

On 06/07/2012 10:47 AM, Namjae Jeon wrote:

> Hi Bruce, Trond.
> 
> As you know, Currently umount results in busy on NFS server although
> user tried to succeed to umount on NFS client.
> I suggest to add umount procedure to avoid umount busy issue.
> When calling umount on NFS client, The resources(exportfs entries
> cache) of mount point will be flushed on NFS server. and umount will
> be succeed without busy issue.
> 
> how do you think about this suggestion ?
> 


I second this request, what is needed so when all clients unmounted,
the system comes back to the sate it was before any clients have
mounted. i.e filesystems is not referenced and may unmount cleanly.
(This also happens with >= 4.0 clients only, so no excuses)

This is a real problem for me, on Fedora machines. Because I export
iscsi devices which are network devices, and in the shutdown procedure
for some reason the "service nfs stop" of the server is much much to
late. the original umount of exofs (-o _netdev) fails because it's
held by NFSD, the iscsi devices go away regardless, and when nfsd
finally releases exofs, it gets deadlocked on some error handling.
OK I know I must fix the stuck-ness, but the problem will remain.
The FS will not unmount cleanly because it will only attempt
an unmount after its devices are gone. This will be solved if
nfsd would release its hold on the FS when all clients are gone.

It was on my TODO to fix this for a long time, but I seem to be
too busy with more urgent matters. (What's the point of fixing the
shutdown if the steady state doesn't work yet)

If someone has investigated the matter and knows what to do I would
appreciate any insights, and/or patches would be wonderful ;-)

> Thanks.
> 

<>

Thanks
Boaz


  reply	other threads:[~2012-06-07  8:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-07  7:47 Re: Re: [Problem]NFS Server – Umount results in Device Busy Namjae Jeon
2012-06-07  8:13 ` Boaz Harrosh [this message]
2012-06-07  9:43   ` Namjae Jeon
2012-06-07 10:16     ` Boaz Harrosh
2012-06-07 10:36       ` Namjae Jeon
2012-06-07 11:33   ` J. Bruce Fields
2012-06-07 21:59     ` Boaz Harrosh
2012-06-07 22:05       ` Boaz Harrosh
2012-06-08  7:23       ` Namjae Jeon
2012-06-11 12:28       ` J. Bruce Fields
2012-06-07 23:41     ` Namjae Jeon
  -- strict thread matches above, loose matches on Subject: below --
2012-05-10  6:59 AMIT SAHRAWAT
2012-05-10 10:38 ` J. Bruce Fields

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=4FD06290.7050004@panasas.com \
    --to=bharrosh@panasas.com \
    --cc=Trond.Myklebust@netapp.com \
    --cc=a.sahrawat@samsung.com \
    --cc=bfields@fieldses.org \
    --cc=linkinjeon@gmail.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=namjae.jeon@samsung.com \
    /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;
as well as URLs for NNTP newsgroup(s).