Subject: Re: MNT_NOSHARE for non-exportable fs [was: Removing tmpfs' experimental status
To: YAMAMOTO Takashi <>
From: Bill Studenmund <>
List: tech-kern
Date: 10/25/2006 08:21:35
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Oct 25, 2006 at 09:11:50PM +0900, YAMAMOTO Takashi wrote:
> > > - why "share" rather than "export"?
> >=20
> > I chose "share" because "export" is too tightly coupled with NFS. Howev=
er, I'm
> > sure my point of view can be swayed ;-)
> it's actually tightly coupled with nfs, isn't it?
> eg. how can it prevent smbd or apache from exporting the filesystem?

We teach apache or smbd to look for it?

> > > - what's the point to expose it as a mount option?
> > >   sys_mount is not an appropriate interface to control nfs exportabil=
> > >   these days.  to specify filesystem characteristics,
> > >   IMNT_ is more appropriate.
> >=20
> > I'm exposing it as a mount option so that userland knows it's there. It=
's a
> > clear indicater of _why_ exporting doesn't work, "noshare" (or "noexpor=
t") can
> > be seen from the mount options.
> i believe that mount is a wrong way to show this kind of
> filesystem characteristics.

I think it depends on the exact semantics we are trying to expose. A "No=20
one can access this mount point now" option is muddled, and I think=20
incorrect (and not what this code does).

I think a "I don't want this file system exported/shared EVER" semantic
can make sense as a mount option. The administrator can add the flag in=20
/etc/fstab, and then nothing else in the system will (or should) let it=20
get exported.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.3 (NetBSD)