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

On Sun, Jan 28, 2007 at 02:16:53PM -0500, rick@snowhite.cis.uoguelph.ca wro=
te:
> > No. File handles within an fs will still be used in the same way. We wi=
ll
> > just have a different mapping between the file system specific info and
> > the on-wire NFS file handle.
>=20
> I'm not sure how you are going to implement "different mapping"? Remember
> that file handles are T stable, which means they refer to a file even
> long after the file is deleted, must work across server reboots, etc.

Yes and no. There's always a practical life to a file handle. At an=20
extreme, I doubt anyone cares about a file handle for a file system that=20
was destroyed over a decade ago. Or at least hardly anyone will.

We can change the mapping of a file handle if we say we are making a=20
disruptive change to our NFS on-wire data. i.e. you have to unmount the=20
clients before updating the server then you can remount after the update.

The idea would be to 1) add some sort of long-term key that is passed in=20
with each export. Something that is stable across boots. 2) add space in=20
the file handle to indicate which export point a file handle came from,=20
and 3) add some sort of authentication so that we can tell if it's likely=
=20
the file handle has not been tampered with. The thought is to do something=
=20
so that it's harder to forge file handles.

Take care,

Bill

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

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

iD8DBQFFvjNPWz+3JHUci9cRAiFgAKCQjKX4iNLhI3Ay/tt8wOZ1inqoYACdH4Pc
bVln/9WiDH84XK/6knJ/y0U=
=GK0G
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--