All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: spencer shepler <spencer.shepler@gmail.com>
Cc: Steve Dickson <SteveD@redhat.com>,
	Linux NFS Mailing list <linux-nfs@vger.kernel.org>
Subject: Re: Making crossmnt a default export option
Date: Wed, 1 Apr 2009 12:06:23 -0400	[thread overview]
Message-ID: <20090401160623.GD5018@fieldses.org> (raw)
In-Reply-To: <b314b0e60903251736i42b1113cj6aafc058d775b2c2@mail.gmail.com>

On Wed, Mar 25, 2009 at 07:36:45PM -0500, spencer shepler wrote:
> On Wed, Mar 25, 2009 at 1:53 PM, Steve Dickson <SteveD@redhat.com> wrote:
> > Hello,
> >
> > What would be the ramifications of turning on the crossmnt
> > option on by default? Currently the the default is nocrossmnt.
> >
> > In my recent work with pseudo exports, it has become very apparent
> > that having the crossmnt always set, especially with multi file
> > system exports, allows mount to "just work"!
> >
> > So historically what is the reason for not allowing the clients
> > to always cross file systems? Is it a security issue?
> > And again, what would be the ramifications always allowing, by
> > default, clients to cross file systems?
> 
> As Trond mentioned, the OpenSolaris client doesn't automatically
> create mount points when crossing the server's filesystem boundaries
> (for NFSv3).
> NFSv4 support for that behavior is now present for OpenSolaris.
> 
> So the risk is running into clients that don't behave like the Linux
> client and then "mv" will not be able to determine the appropriate
> behavior when mv'ing files between those filesystems.

And some applications may be confused when they see different files that
appear to be on the same filesystem but that have different inodes.
Etc.

And this requires people to change their exports.  We've done this
before (with sync and subtree_check), but it's something to avoid if at
all possible.

So preserving the current behavior for v2/v3 is important.

--b.

      reply	other threads:[~2009-04-01 16:06 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-25 18:53 Making crossmnt a default export option Steve Dickson
2009-03-25 18:58 ` Benny Halevy
2009-03-25 19:23 ` Trond Myklebust
2009-03-26  0:36 ` spencer shepler
2009-04-01 16:06   ` J. Bruce Fields [this message]

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=20090401160623.GD5018@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=SteveD@redhat.com \
    --cc=linux-nfs@vger.kernel.org \
    --cc=spencer.shepler@gmail.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.