stale nfs file handle with exported loopback mounts

-----Urspr=FCngliche Nachricht-----
Von: Neil Brown <[email protected]>
Gesendet: 01.11.07 05:26:50
An: [email protected]
CC: "J. Bruce Fields" <[email protected]>, [email protected]
Betreff: Re: [NFS] stale nfs file handle with exported loopback mounts

=

Quoted 7 lines · On Wednesday October 31, [email protected] wrote:

ok, i just wanted to tell that this isn`t the right way to go imho. =

some time ago i have tested exporting a parent dir containing several loopback mounted iso images with some pre-1.1.0 nfs-utils version and it worked - so =EC wonder why it now seems to have issues as things should have gone stable..... =

=

We have a way of breaking things sometimes.... It's called "progress". :-)
=

The short answer is that there is a bug in mountd which is fixed by this patch:
=

utils/mountd/cache.c +1 -1

index ce1a5a9..fd317cd 100644
@@ -508,7 +508,7 @@ void nfsd_fh(FILE *f)
 	 */
 	qword_printint(f, 0x7fffffff);
 	if (found)
-		qword_print(f, found->e_path);
+		qword_print(f, found_path);
 	qword_eol(f);
  out:
 	free(found_path);

=

=

The longer answer is that there is also a bug in "mount.nfs" which is unrelated but was slowing me down in chasing this bug, and there is also a bug in the NFS client which was causing my client oops and need a reboot every time I triggered this bug in mountd, which further slowed me down.
=

The effect of this bug in mountd is that when the NFS client calls GETATTR on the root of the subordinate filesystem (e.g. your loop-mounted isos), it got attr information about the parent. ie. the top-level exported filesystem (/export in your case I think). This has a different 'fsid' than the nfs client was expecting and the NFS client got confused in various ways.
=

Thanks for your problem report - it helped find 3 bugs! =

I'll get proper patches or bug report off to the relevant maintainers shortly.
=

NeilBrown
=