Subject: Re: exporting -ro nfs
To: None <email@example.com, firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 02/01/2007 14:31:41
Content-Type: text/plain; charset=us-ascii
On Thu, Feb 01, 2007 at 01:49:07PM -0500, George Georgalis wrote:
> On Mon, Jan 29, 2007 at 10:39:15PM -0800, Bill Studenmund wrote:
> >There might be a performance change, but it'd still be the exact same NFS
> >we have now. Given all the other things in NFS, I doubt there'd be much=
> >performance impact. As Jason mentioned, the main idea here is that inste=
> >of having "mount" info in the file handle, we have some form of "export"=
> >info. It'd mean a changed multiplexing/demultiplexing, but it wouldn't b=
> >hard to do.
> Hey that's great!
Note: in re-reading your message, I realized I answered something a little=
different. With what I describe, we can limit access based on export=20
point. So if you got your file handle from a r/o export, you always can't=
write. That's not the same thing as enforcing mode masks on NFS clients,=20
but it's most likely what people really want.
> If/when this gets in place no doubt exports(5) will be updated.
> It might be worthwhile to clarify you can only export a local
> filesystem, ie an iso vnode mount or nfs mount from another host
> won't export... as I'm writing this I wonder if this restriction
> will continue under the new system? if the file handle contains
> the export info we are no longer bound to the local filesystem
NFS exporting an NFS mount can run into the problem that file handle sizes=
are fixed (as I recall) for NFS v2, and to add this extra info, we'd have=
to gobble up "reserved" space in the input file handle. True, most file=20
handles won't care, but some may.
Also, why would you want to do this? As an admin, I'd dislike it if you=20
shared my export, because then I (the admin of the share you're mounting=20
as a client) lose control of access.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----