Linux NFS development
 help / color / mirror / Atom feed
From: devzero@web.de
To: Neil Brown <neilb@suse.de>
Cc: "J. Bruce Fields" <bfields@fieldses.org>, NFS@lists.sourceforge.net
Subject: Re: stale nfs file handle with exported loopback mounts
Date: Sat, 10 Nov 2007 16:14:49 +0100	[thread overview]
Message-ID: <2077285183@web.de> (raw)

Hi Neil, =


as Andreas told that the kernel fix will be in one of the next openSuSE ker=
nel updates i`m wondering if that also applies to the mountd patch.
Will there be an update package for nfs-utils or is this just too minor iss=
ue for releasing an update package ?

regards
roland


> -----Urspr=FCngliche Nachricht-----
> Von: Neil Brown <neilb@suse.de>
> Gesendet: 01.11.07 05:26:50
> An: devzero@web.de
> CC: "J. Bruce Fields" <bfields@fieldses.org>, NFS@lists.sourceforge.net
> Betreff: Re: [NFS] stale nfs file handle with exported loopback mounts


> =

> On Wednesday October 31, devzero@web.de 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:
> =

> diff --git a/utils/mountd/cache.c b/utils/mountd/cache.c
> index ce1a5a9..fd317cd 100644
> --- a/utils/mountd/cache.c
> +++ b/utils/mountd/cache.c
> @@ -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
> =



_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=3D100071&distributionid=3D000000000066


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

             reply	other threads:[~2007-11-10 15:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-10 15:14 devzero [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-11-02 19:37 stale nfs file handle with exported loopback mounts devzero
2007-11-02 19:42 ` J. Bruce Fields
2007-11-04 20:30   ` J. Bruce Fields
2007-11-05  9:59     ` Andreas Gruenbacher
2007-11-02 19:06 devzero
2007-11-02 19:23 ` J. Bruce Fields
2007-11-02 19:24   ` J. Bruce Fields
2007-10-31 22:50 devzero
2007-11-01  4:26 ` Neil Brown
2007-10-31 22:19 devzero
2007-10-31 22:39 ` J. Bruce Fields
2007-10-31 20:46 devzero
2007-10-31 20:57 ` J. Bruce Fields
2007-10-30 20:05 devzero
2007-10-27 16:13 devzero
2007-10-30  5:14 ` Neil Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2077285183@web.de \
    --to=devzero@web.de \
    --cc=NFS@lists.sourceforge.net \
    --cc=bfields@fieldses.org \
    --cc=neilb@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox