--+HP7ph2BbKc20aGI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=
=20
> >performance impact. As Jason mentioned, the main idea here is that inste=
ad=20
> >of having "mount" info in the file handle, we have some form of "export"=
=20
> >info. It'd mean a changed multiplexing/demultiplexing, but it wouldn't b=
e=20
> >hard to do.
>=20
> Hey that's great!

Note: in re-reading your message, I realized I answered something a little=
=20
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=
=20
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
> right?

NFS exporting an NFS mount can run into the problem that file handle sizes=
=20
are fixed (as I recall) for NFS v2, and to add this extra info, we'd have=
=20
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.

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFwmpNWz+3JHUci9cRApE7AJ9QqFd6XkJvgyyQSeQkMJ7iK75WOwCghboJ
s8Oezg2YVHh8dEDt031Gf0Y=
=2A88
-----END PGP SIGNATURE-----

--+HP7ph2BbKc20aGI--