mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Frank van Maarseveen <frankvm@frankvm.com>,
	Hua Zhong <hzhong@gmail.com>,
	"'Linux Kernel Mailing List'" <linux-kernel@vger.kernel.org>,
	akpm@linux-foundation.org
Subject: Re: recent nfs change causes autofs regression
Date: Fri, 31 Aug 2007 00:44:45 -0400	[thread overview]
Message-ID: <1188535485.6626.85.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <alpine.LFD.0.999.0708302038310.25853@woody.linux-foundation.org>

On Thu, 2007-08-30 at 20:49 -0700, Linus Torvalds wrote:
> 
> On Thu, 30 Aug 2007, Trond Myklebust wrote:
> > 
> > Which is better than having it fail silently, or giving you a mount with
> > the wrong mount options.
> 
> No, Trond.
> 
> That commit gets reverted or fixed. It's a regression, and your theories 
> that it's "better" that way are obviously broken.
> 
> It's obviously broken because you seem to say that you know better, even 
> though you also admit that:
> 
>   "How is the NFS client to know that these directories are disjoint, or
>    that no-one will ever create a hard link from one directory to another? 
>    To my knowledge, the only way to ensure this is to put them on 
>    different disk partitions."
> 
> the point being that you just disallowed people from doing things that are 
> sane but _potentially_ dangerous. That's now how we work. The UNIX way sis 
> to give people rope - if you cannot *prove* that what they are doing is 
> wrong, then you damn well better not disallow it.
> 
> No regressions, Trond. Especially not for stuff that used to work, was 
> used, and that could be sanely expected to work (which this *definitely*
> sounds like).

It did not. The previous behaviour was to always silently override the
user mount options.

> Please send in a fix. If the fix involves making "nosharecache" the 
> default, then that is better than making policy decisions like this in the 
> kernel. The kernel should do what the user asks and not put in unnecessary 
> roadblocks.

This is _not_ a kernel policy decision. The kernel is simply informing
the user that it cannot fulfil the mount request as specified. Exactly
why do you think that NFS should be any different from other filesystems
when it comes to this?

AFAIK, every other filesystem will give you an EBUSY if you try to mount
a partition with -oro if you are already mounting somewhere else with
-orw. Every filesystem will give you an EBUSY if you try to mount the
partition with -oacl if it is mounted somewhere else with -onoacl. The
reason: exactly the same as NFS, the caches cannot remain consistent
when you try to mount two different super blocks that both refer to the
same underlying filesystem.

Trond


  parent reply	other threads:[~2007-08-31  4:45 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-30 21:07 Hua Zhong
2007-08-30 22:37 ` Trond Myklebust
2007-08-30 22:47   ` Hua Zhong
2007-08-30 23:22     ` Trond Myklebust
2007-08-30 23:30       ` Hua Zhong
2007-08-30 23:37         ` Trond Myklebust
2007-08-30 23:44           ` Hua Zhong
2007-08-31  4:31             ` Trond Myklebust
2007-08-31  4:38               ` Linus Torvalds
2007-08-31  4:47                 ` Hua Zhong
2007-08-31  4:57                 ` Trond Myklebust
2007-08-31  5:09               ` Ian Kent
2007-08-31  7:50               ` Matthias Schniedermeyer
2007-08-31  1:24   ` Andrew Morton
2007-08-31  4:33     ` Trond Myklebust
2007-08-31  3:49   ` Linus Torvalds
2007-08-31  3:57     ` Hua Zhong
2007-08-31  4:44     ` Trond Myklebust [this message]
2007-08-31  4:59       ` Linus Torvalds
2007-08-31  5:04         ` Trond Myklebust
2007-08-31  5:16           ` Linus Torvalds
2007-08-31  7:40             ` Jakob Oestergaard
2007-08-31  8:07               ` Linus Torvalds
2007-08-31  8:51                 ` Jakob Oestergaard
2007-08-31 16:43                   ` Linus Torvalds
2007-09-03 13:20                     ` Jakob Oestergaard
2007-09-03 13:43                       ` Martin Knoblauch
2007-08-31 12:11                 ` Trond Myklebust
2007-08-31 13:12                   ` Frank van Maarseveen
2007-08-31 13:50                     ` Trond Myklebust
2007-08-31 14:42                       ` Frank van Maarseveen
2007-09-04  7:51                 ` David Howells
2007-08-31  8:28               ` Frank van Maarseveen
2007-08-31  5:24           ` Hua Zhong
2007-08-31  5:38         ` Ian Kent
2007-08-31  8:54           ` Martin Knoblauch
2007-08-31 16:21     ` Trond Myklebust
2007-08-31 17:01       ` Linus Torvalds
2007-08-31 19:03         ` Trond Myklebust
2007-08-31 18:47       ` Hua Zhong
2007-08-31 19:13         ` Trond Myklebust
2007-08-31 19:35           ` Hua Zhong
2007-08-31 19:41           ` Hua Zhong
2007-09-02  0:58       ` Bill Davidsen
2007-09-04  7:54       ` David Howells
2007-09-05 12:35         ` Bill Davidsen
2007-09-05 12:44         ` Ian Kent
2007-09-05 16:26           ` Trond Myklebust
2007-09-05 15:34         ` David Howells
2007-09-05 15:37         ` David Howells
2007-09-05 15:50           ` Trond Myklebust
2007-09-06  5:23             ` Ian Kent
2007-09-04  8:02       ` David Howells
2007-09-04  8:35       ` David Howells
2007-09-04  9:04         ` Linus Torvalds
2007-08-31  8:14 ` Frank van Maarseveen
2007-08-31  9:05   ` Ian Kent

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=1188535485.6626.85.camel@heimdal.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=akpm@linux-foundation.org \
    --cc=frankvm@frankvm.com \
    --cc=hzhong@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®