linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Boaz Harrosh <bharrosh@panasas.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Namjae Jeon <linkinjeon@gmail.com>,
	"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: Fri, 8 Jun 2012 00:59:10 +0300	[thread overview]
Message-ID: <4FD1242E.1010909@panasas.com> (raw)
In-Reply-To: <20120607113358.GB8684@fieldses.org>

On 06/07/2012 02:33 PM, J. Bruce Fields wrote:

> On Thu, Jun 07, 2012 at 11:13:04AM +0300, Boaz Harrosh wrote:


> 
> I'm not sure how adding an "unmount" rpc to the protocol would really
> help here, if that's what you're asking for.
> 


Please elaborate a bit. I'm not familiar with the details of this
discussion.

> If you're just looking for a command you could run on the server after
> all the clients have unmounted--"exportfs -f" or "service stop nfsd" (or
> equivalent) should do the job.
> 

man exportfs
       -f     In 'new' mode, flush everything out of the kernels export table.
              Any clients that are active will get new entries added by mountd
              when they make their next request.

What if: (Just fantasizing here, if I understand the above text correctly)
* NFS4: A bit like expire client, as long as client has state on the server
        he needs to refresh his leases so not to expire with some kind of
        activity or renewals.
	If a client has no state and 2*expiry timeout passed then it is
	individually "exportfs -f". This is safe because on renewed activity
	it will get it's mountd entries renewed safely (did I understand
	this correctly?

* NFS3: Same as above But with say X*expiry timeout after last activity
	Same safeness as above.

Any "unmount rpc" will expedite the above without waiting for timeout

<>

> 
> Note nfsd doesn't really know when that is.  Even with NFSv4, processes
> can be using the filesystem without holding state on the server: they
> might just have a current working directory in the filesystem, or have a
> device special file open.
> 


How does the magic of above statement works? quote:
    "will get new entries added by mountd when they make their next request"

<>

> 
> My first concern would be to fix any ordering bugs in the systemd
> configuration, or any reference count leaks.
> 


I'm currently shooting in the dark, I have not investigated this at all,
do to lack of time. It should be the same with an ext4 over iscsi device
re-exported by NFS. You must mount the ext4 as "-o _netdev" otherwise
ext4 mount itself will have a problem.

> --b.


Thanks Bruce, we'll keep this on a back burner until we can come back to
it. A TODO.

But Jeon, please do send in your proposal code, I'd like to see it.

Thanks
Boaz

  reply	other threads:[~2012-06-07 21:59 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
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 [this message]
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=4FD1242E.1010909@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).