Date: Wed, 17 Dec 2014 13:34:50 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories Message-ID: <5491E8EA.30902@pinyon.org> In-Reply-To: <5490FB0A.9060702@pinyon.org> References: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> <201412161337.58789.jhb@freebsd.org> <5490FB0A.9060702@pinyon.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/16/14 20:39, Russell L. Carter wrote: > > > On 12/16/14 11:37, John Baldwin wrote: >> On Monday, December 15, 2014 3:59:29 pm Rick Macklem wrote: > > [...] > >>> What I suspect might cause this is one of two things: >>> 1 - The modify time of the file is now changing at a time the Linux >>> client doesn't expect, due to changes in ZFS or maybe TOD clock >>> resolution. (At one time, the TOD clock was only at a resolution >>> of 1sec, so the client wouldn't see the modify time change often. >>> I think it is now at a much higher resolution, but would have to >>> look at the code/test to be sure.) >> >> No, it's still only a second resolution on FreeBSD by default. You can >> make this precise on the NFS server by setting the >> vfs.timestamp_precision >> sysctl to 3. We should probably be using that by default for at least >> server-class systems. >> > > Hmm, what's this? Let's see: > > rcarter@feyerabend> uname -a > FreeBSD feyerabend.n1.pinyon.org 10.1-STABLE FreeBSD 10.1-STABLE #1 > r275516+3a52b5f(stable-jhb-em): Sat Dec 6 10:37:16 MST 2014 > toor@feyerabend.n1.pinyon.org:/usr/obj/usr/src/sys/RLCGSV amd64 > rcarter@feyerabend> man -k vfs.timestamp_precision > vfs.timestamp_precision: nothing appropriate > rcarter@feyerabend> sysctl -d vfs.timestamp_precision > vfs.timestamp_precision: File timestamp precision (0: seconds, 1: sec + > ns accurate to 1/HZ, 2: sec + ns truncated to ms, 3+: sec + ns (max. > precision)) > rcarter@feyerabend> sysctl vfs.timestamp_precision > vfs.timestamp_precision: 0 > > Ah, that's *VERY* interesting. I am unfortunately leaving the > physical vicinity of my server farm soon, so not the right time for > experiments. But I have been whining for some time now about what > looks to be very similar to gerrit.kuehn's symptoms. I see them on > installworlds via NFS v4.1, on -current or stable/10-trunk. About 9 > out of 10 installs fail trying to rebuild parts of the tree. I > finally resorted to copying /usr/obj* around and then just mounting > /usr/src via NFS. ick. Oh, and also buildworld/buildkernel -j1. A > pity on a cluster where 8 cores/system are the norm. But now I have > something sensible to try. Looking forward to it. After figuring out a way to test this reversibly, I tried the following: server & client vfs.timestamp_precision=3, make -j12 buildworld/kernel, and make installworld -j1 on the client => fail, in /usr/src/sys/boot server & client vfs.timestamp_precision=0, make -j1 build/install, succeeds. Worth a shot anyway... Cheers, Russell > Happy holidays, and cheers! > Russell > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5491E8EA.30902>