From: Boaz Harrosh <bharrosh@panasas.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: Benny Halevy <bhalevy@panasas.com>,
Fred Isaman <iisaman@netapp.com>,
NFS list <linux-nfs@vger.kernel.org>
Subject: Re: [RFC] pnfs: Send layoutreturn, if Return-On-Close is set
Date: Thu, 26 May 2011 17:45:23 +0300 [thread overview]
Message-ID: <4DDE6783.5@panasas.com> (raw)
In-Reply-To: <1306419397.2984.14.camel@lade.trondhjem.org>
On 05/26/2011 05:16 PM, Trond Myklebust wrote:
> On Thu, 2011-05-26 at 16:19 +0300, Boaz Harrosh wrote:
>> Every thing was ready, in pnfs_roc(). The segments released
>> and the LO state blocked til after the close is done. All that
>> is needed is to send the actual layoutreturn synchronously.
>
> Why would we want to do this?
>
> Return-on-close was initially considered useful only for debugging.
>
What ??
> At the interim IETF meeting in Sunnyvale, we also discussed the case
> where the forgetful client has forgotten the layout: in this case the
> server may decide to forget the layout too. There is no controversy in
> doing this, since both the client and the server know that any
> outstanding layout is supposed to be returned (and if there is a
> problem, then the server always has the option of sending a
> CB_LAYOUTRECALL).
>
OK I didn't know that. So what you are saying is that if the server see
a final close he can go and provocative free all segments marked with ROC?
If so then someone should fix the Linux server. Because currently it never
frees them. On a modest machine like the UML I use. Few 10s of "git checkout linux"
crash the machine with oom. Today they are only freed on client umount.
> Adding a synchronous call to close is in any case a bug since close can
> on occasion be sent in situations where we don't allow sleeping.
>
This is done only on the final close. Isn't the very final call sync?
Ok re-inspecting the code I can see that nfs4_do_close also takes a wait flag.
I thought that the last close should always be waiting for all operations
to end before proceeding with the close. That's how it is at the VFS level
but I guess life is hard. So the only possible solution is within the same
compound as the close. (not that we need it as you say)
> Cheers
> Trond
Thanks
Boaz
next prev parent reply other threads:[~2011-05-26 14:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-26 13:19 [RFC] pnfs: Send layoutreturn, if Return-On-Close is set Boaz Harrosh
2011-05-26 14:16 ` Trond Myklebust
2011-05-26 14:45 ` Boaz Harrosh [this message]
2011-05-26 15:04 ` Trond Myklebust
2011-05-26 15:19 ` More NFSv4.1 issues [WAS: Re: [RFC] pnfs: Send layoutreturn, if Return-On-Close is set] Trond Myklebust
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=4DDE6783.5@panasas.com \
--to=bharrosh@panasas.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bhalevy@panasas.com \
--cc=iisaman@netapp.com \
--cc=linux-nfs@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.