[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-fs
Subject:    Re: NFS corruption in recent HEAD.
From:       Rick Macklem <rmacklem () uoguelph ! ca>
Date:       2011-11-27 14:27:10
Message-ID: 1308447178.437372.1322404030886.JavaMail.root () erie ! cs ! uoguelph ! ca
[Download RAW message or body]

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
_______________________________________________
freebsd-fs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-fs
To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
[prev in list] [next in list] [prev in thread] [next in thread]