Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Nov 2011 09:27:10 -0500 (EST)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Pawel Jakub Dawidek <pjd@FreeBSD.org>
Cc:        freebsd-fs@FreeBSD.org
Subject:   Re: NFS corruption in recent HEAD.
Message-ID:  <1308447178.437372.1322404030886.JavaMail.root@erie.cs.uoguelph.ca>
In-Reply-To: <20111127105913.GH8794@garage.freebsd.pl>

next in thread | previous in thread | raw e-mail | index | archive | help
Pawel Jakub Dawidek wrote:
> On Sat, Nov 26, 2011 at 09:03:46PM -0500, Rick Macklem wrote:
> > Pawel Jakub Dawidek wrote:
> > > Hi.
> > >
> > > I'm booting machine over the network using new NFS client and I'm
> > > getting those warnings on boot:
> > >
> > > /etc/rc.subr: 666: Syntax error: "(" unexpected (expecting ";;")
> [...]
> > Oh, and maybe you could try reverting r227543 in the client
> > (assuming
> > the client is post-r227543). Maybe that file's vnode type isn't set
> > to
> > VREG early in the diskless booting and needs the ncl_flush() for
> > some
> > reason.
> >
> > I don't actually have a bug that needs r227543 to fix it. It just
> > seemed
> > incorrect to flush non-VREG files (particularily VDIR). As such,
> > reverting
> > it wouldn't be a big deal.
> 
> I haven't tried reverting anything yet, but I think I was able to
> reproduce this with old NFS client as well. The problem goes away when
> I
> comment out root mount point from /etc/fstab or remove mntudp from
> mount
> options. NFS root is mounted using TCP, AFAIK and it probably happens
> when startup scripts (rc.d/mountcritremote) remounts root with mntudp
> flag. The rc.subr warning starts to appear just after mountcritremote
> is
> called.
> 
Ok, I'm not surprised that the recent commits I've done weren't related,
since I couldn't think how they would have been. (Although the "readahead"
option can now override the default of 1, the readahead code hasn't changed
in ages. The new NFS code is just a clone of the old stuff.) And I doubt
fsync() was being called for the file (plus it should be VREG), so I can't
think how that might have affected it, either.

It sounds like the mount update that changed TCP->UDP caused it. I'll take
a closer look at that code. Maybe shutting down the TCP socket results in
a read failing, leaving an invalid buffer cache block that isn't marked
invalid properly (or something like that)?

Still seems to be a mystery to me.

Thanks for digging into this and please let me know if you figure out more, rick

> --
> Pawel Jakub Dawidek http://www.wheelsystems.com
> FreeBSD committer http://www.FreeBSD.org
> Am I Evil? Yes, I Am! http://yomoli.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1308447178.437372.1322404030886.JavaMail.root>