linux-nfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.com>
To: Jeff Layton <jlayton@redhat.com>,
	Joshua Watt <jpewhacker@gmail.com>,
	"Trond Myklebust" <trond.myklebust@primarydata.com>,
	"J . Bruce Fields" <bfields@fieldses.org>
Cc: linux-nfs@vger.kernel.org, Al Viro <viro@zeniv.linux.org.uk>,
	"David Howells" <dhowells@redhat.com>,
	linux-api@vger.kernel.org
Subject: Re: [RFC v4 0/9] NFS Force Unmounting
Date: Fri, 08 Dec 2017 13:10:40 +1100	[thread overview]
Message-ID: <87bmjaq89r.fsf@notabene.neil.brown.name> (raw)
In-Reply-To: <1512565420.4048.21.camel@redhat.com>

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

On Wed, Dec 06 2017, Jeff Layton wrote:

> On Wed, 2017-12-06 at 10:34 +1100, NeilBrown wrote:
>> 
>> The new semantic for MNT_DETACH|MNT_FORCE is interesting.
>> As it was never possible before (from /bin/umount), it should be safe to
>> add a new meaning.
>> The meaning is effectively "detach the filesystem from the namespace and
>> detach the transport from the filesystem", which sounds like it is
>> useful.
>> It is worth highlighting this, and maybe even cc:ing
>> linux-api@vger.kernel.org ... done that.
>> 
>
> I'm not thrilled with the new flag combo, personally. Given that we're
> introducing new behavior here, I think it wouldn't hurt to add a new
> UMOUNT_* flag for this (UMOUNT_NUKE_FROM_ORBIT?).

Suppose we did... MNT_FORCE_PONIES. What would be the semantics of this
flag?  Once we had it, would anyone ever want to use MNT_FORCE again?

MNT_FORCE is already fairly heavy handled.  It abort an arbitrary
collections of RPC requests being sent for the given filesystem, no
matter where else that filesystem might be mounted.
Is it ever safe to use this flag unless you have good reason to believe
that the server is not available and there is no point pretending any
more?
And if that is the case, why not use the new MNT_FORCE_PONIES which is
at least predictable and reliable.

We've talking a lot about the one NFS filesystem being mounted in
multiple containers.  MNT_FORCE is already a problem for such mounts as
one contains can kill requests generated from another container.  Maybe
MNT_FORCE needs to be restricted to "real" root.
Once we restrict it, do we need to keep it from being too harsh?

What would be really nice is a timeout for umount, and for sync.
The timeout only starts when the filesystem stops making progress for
writeback.  If it eventually does timeout, then the caller can fall back
to MNT_DETACH if they are in a container, or MNT_FORCE if not.
(Maybe MNT_FORCE should map to MNT_DETACH in a container??? or maybe
not).

There is a lot here that still isn't clear to me, but one this does seem
to be becoming clear:  MNT_FORCE as it stands is nearly useless and it
would serve is well to find a semantic that it actually useful, and
impose that.

Thanks,
NeilBrown

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

  parent reply	other threads:[~2017-12-08  2:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-17 17:45 [RFC v4 0/9] NFS Force Unmounting Joshua Watt
2017-11-17 17:45 ` [RFC v4 1/9] SUNRPC: Add flag to kill new tasks Joshua Watt
2017-12-05 22:59   ` NeilBrown
2017-11-17 17:45 ` [RFC v4 2/9] SUNRPC: Expose kill_new_tasks in debugfs Joshua Watt
2017-11-17 17:45 ` [RFC v4 3/9] SUNRPC: Simplify client shutdown Joshua Watt
2017-11-17 17:45 ` [RFC v4 4/9] namespace: Add umount_end superblock operation Joshua Watt
2017-12-06 11:54   ` Jeff Layton
2017-12-06 12:14   ` Al Viro
2017-12-06 12:33     ` Al Viro
2017-12-06 15:41       ` Joshua Watt
2017-11-17 17:45 ` [RFC v4 5/9] NFS: Kill RPCs for the duration of umount Joshua Watt
2017-12-05 23:07   ` NeilBrown
2017-11-17 17:45 ` [RFC v4 6/9] NFS: Add debugfs for nfs_server and nfs_client Joshua Watt
2017-11-17 17:45 ` [RFC v4 7/9] NFS: Add transient mount option Joshua Watt
2017-12-06 12:23   ` Jeff Layton
2017-11-17 17:45 ` [RFC v4 8/9] NFS: Don't shared transient clients Joshua Watt
2017-11-17 17:45 ` [RFC v4 9/9] NFS: Kill all client RPCs if transient Joshua Watt
2017-12-04 14:36 ` [RFC v4 0/9] NFS Force Unmounting Joshua Watt
2017-12-05 23:34   ` NeilBrown
2017-12-06 13:03     ` Jeff Layton
2017-12-06 16:40       ` Joshua Watt
2017-12-08  2:10       ` NeilBrown [this message]
2017-12-14 18:22         ` Joshua Watt
2017-12-14 21:52           ` NeilBrown
2017-12-18 21:48             ` Joshua Watt

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=87bmjaq89r.fsf@notabene.neil.brown.name \
    --to=neilb@suse.com \
    --cc=bfields@fieldses.org \
    --cc=dhowells@redhat.com \
    --cc=jlayton@redhat.com \
    --cc=jpewhacker@gmail.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trond.myklebust@primarydata.com \
    --cc=viro@zeniv.linux.org.uk \
    /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).