All of lore.kernel.org
 help / color / mirror / Atom feed
From: bfields@fieldses.org (J. Bruce Fields)
To: NeilBrown <neilb@suse.com>
Cc: Steve Dickson <SteveD@redhat.com>,
	Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH 3/8] mountd: remove 'dev_missing' checks
Date: Mon, 18 Jul 2016 16:01:21 -0400	[thread overview]
Message-ID: <20160718200121.GC12304@fieldses.org> (raw)
In-Reply-To: <20160714022643.5874.84409.stgit@noble>

On Thu, Jul 14, 2016 at 12:26:43PM +1000, NeilBrown wrote:
> I now think this was a mistaken idea.
> 
> If a filesystem is exported with the "mountpoint" or "mp" option, it
> should only be exported if the directory is a mount point.  The
> intention is that if there is a problem with one filesystem on a
> server, the others can still be exported, but clients won't
> incorrectly see the empty directory on the parent when accessing the
> missing filesystem, they will see clearly that the filesystem is
> missing.
> 
> It is easy to handle this correctly for NFSv3 MOUNT requests, but what
> is the correct behavior if a client already has the filesystem mounted
> and so has a filehandle?  Maybe the server rebooted and came back with
> one device missing.  What should the client see?
> 
> The "dev_missing" code tries to detect this case and causes the server
> to respond with silence rather than ESTALE.  The idea was that the
> client would retry and when (or if) the filesystem came back, service
> would be transparently restored.
> 
> The problem with this is that arbitrarily long delays are not what
> people would expect, and can be quite annoying.  ESTALE, while
> unpleasant, it at least easily understood.  A device disappearing is a
> fairly significant event and hiding it doesn't really serve anyone.

It could also be a filesystem disappearing because it failed to mount in
time on a reboot.

> So: remove the code and allow ESTALE.

I'm not completely sure I understand the justification.

I don't like the current behavior either--I'd be happy if we could
deprecate "mountpoint" entirely--but changing it now would seem to risk
regressions if anyone depends on it.

--b.

> 
> Signed-off-by: NeilBrown <neilb@suse.com>
> ---
>  utils/mountd/cache.c |   12 ------------
>  1 file changed, 12 deletions(-)
> 
> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
> index ec86a22613cf..346a8b3af8b5 100644
> --- a/utils/mountd/cache.c
> +++ b/utils/mountd/cache.c
> @@ -687,7 +687,6 @@ static void nfsd_fh(int f)
>  	char *found_path = NULL;
>  	nfs_export *exp;
>  	int i;
> -	int dev_missing = 0;
>  	char buf[RPC_CHAN_BUF_SIZE], *bp;
>  	int blen;
>  
> @@ -754,11 +753,6 @@ static void nfsd_fh(int f)
>  			if (!is_ipaddr_client(dom)
>  					&& !namelist_client_matches(exp, dom))
>  				continue;
> -			if (exp->m_export.e_mountpoint &&
> -			    !is_mountpoint(exp->m_export.e_mountpoint[0]?
> -					   exp->m_export.e_mountpoint:
> -					   exp->m_export.e_path))
> -				dev_missing ++;
>  
>  			if (!match_fsid(&parsed, exp, path))
>  				continue;
> @@ -801,12 +795,6 @@ static void nfsd_fh(int f)
>  		/* FIXME we need to make sure we re-visit this later */
>  		goto out;
>  	}
> -	if (!found && dev_missing) {
> -		/* The missing dev could be what we want, so just be
> -		 * quite rather than returning stale yet
> -		 */
> -		goto out;
> -	}
>  
>  	if (found)
>  		if (cache_export_ent(buf, sizeof(buf), dom, found, found_path) < 0)
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-07-18 20:01 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-14  2:26 [PATCH 0/8] Assorted mount-related nfs-utils patches NeilBrown
2016-07-14  2:26 ` [PATCH 3/8] mountd: remove 'dev_missing' checks NeilBrown
2016-07-18 20:01   ` J. Bruce Fields [this message]
2016-07-19 22:50     ` NeilBrown
2016-07-21 17:24       ` J. Bruce Fields
2016-08-11  2:51         ` NeilBrown
2016-08-16 15:21           ` J. Bruce Fields
2016-08-18  1:32             ` NeilBrown
2016-08-18  2:57               ` Chuck Lever
2016-08-19  1:31                 ` NeilBrown
2016-08-18 13:57               ` J. Bruce Fields
2016-08-19  1:28                 ` NeilBrown
2016-08-19 17:27                   ` J. Bruce Fields
2016-07-14  2:26 ` [PATCH 8/8] mount: use a public address for IPv6 callback NeilBrown
2016-07-14  2:26 ` [PATCH 1/8] nfs.man: clarify effect of 'retry' option NeilBrown
2016-07-14  2:26 ` [PATCH 6/8] mountd: don't add paths to non-mounted export points to pseudo-root NeilBrown
2016-07-18 20:32   ` J. Bruce Fields
2016-07-19  8:00     ` Chuck Lever
2016-07-19 22:59     ` NeilBrown
2016-07-21 17:33       ` J. Bruce Fields
2016-07-25  7:22         ` NeilBrown
2016-07-28 20:54           ` J. Bruce Fields
2016-07-14  2:26 ` [PATCH 2/8] mountd: remove the --exports-file option NeilBrown
2016-07-18 16:19   ` J. Bruce Fields
2016-07-14  2:26 ` [PATCH 5/8] mountd: Don't export unmounted exports to NFSv4 NeilBrown
2016-07-14  2:26 ` [PATCH 4/8] mountd: cause attempts to access unmounted exportpoints to return ESTALE NeilBrown
2016-07-14  2:26 ` [PATCH 7/8] mount: don't treat temporary name resolution failure as permanent NeilBrown
2016-07-19 23:01   ` NeilBrown

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=20160718200121.GC12304@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=SteveD@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neilb@suse.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 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.