From: Joshua Watt <jpewhacker-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: NeilBrown <neilb-IBi9RG/b67k@public.gmane.org>,
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Trond Myklebust
<trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org>,
"J . Bruce Fields"
<bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
Cc: linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Al Viro <viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.org>,
David Howells <dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC v4 0/9] NFS Force Unmounting
Date: Thu, 14 Dec 2017 12:22:53 -0600 [thread overview]
Message-ID: <1513275773.3888.20.camel@gmail.com> (raw)
In-Reply-To: <87bmjaq89r.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
On Fri, 2017-12-08 at 13:10 +1100, NeilBrown wrote:
> 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.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.
Trying to keep the discussion going... does anyone else have thoughts
on this?
Thanks,
Joshua Watt
>
> Thanks,
> NeilBrown
WARNING: multiple messages have this Message-ID (diff)
From: Joshua Watt <jpewhacker@gmail.com>
To: NeilBrown <neilb@suse.com>, Jeff Layton <jlayton@redhat.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: Thu, 14 Dec 2017 12:22:53 -0600 [thread overview]
Message-ID: <1513275773.3888.20.camel@gmail.com> (raw)
In-Reply-To: <87bmjaq89r.fsf@notabene.neil.brown.name>
On Fri, 2017-12-08 at 13:10 +1100, NeilBrown wrote:
> 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.
Trying to keep the discussion going... does anyone else have thoughts
on this?
Thanks,
Joshua Watt
>
> Thanks,
> NeilBrown
next prev parent reply other threads:[~2017-12-14 18:22 UTC|newest]
Thread overview: 32+ 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
[not found] ` <1512398194.7031.56.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-12-05 23:34 ` NeilBrown
2017-12-05 23:34 ` NeilBrown
[not found] ` <87indksq9q.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-12-06 13:03 ` Jeff Layton
2017-12-06 13:03 ` Jeff Layton
[not found] ` <1512565420.4048.21.camel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2017-12-06 16:40 ` Joshua Watt
2017-12-06 16:40 ` Joshua Watt
2017-12-08 2:10 ` NeilBrown
2017-12-08 2:10 ` NeilBrown
[not found] ` <87bmjaq89r.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-12-14 18:22 ` Joshua Watt [this message]
2017-12-14 18:22 ` Joshua Watt
[not found] ` <1513275773.3888.20.camel-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-12-14 21:52 ` NeilBrown
2017-12-14 21:52 ` NeilBrown
[not found] ` <876099nfiw.fsf-wvvUuzkyo1HefUI2i7LXDhCRmIWqnp/j@public.gmane.org>
2017-12-18 21:48 ` Joshua Watt
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=1513275773.3888.20.camel@gmail.com \
--to=jpewhacker-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org \
--cc=dhowells-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=neilb-IBi9RG/b67k@public.gmane.org \
--cc=trond.myklebust-7I+n7zu2hftEKMMhf/gKZA@public.gmane.org \
--cc=viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn@public.gmane.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.