From owner-freebsd-net@FreeBSD.ORG Wed Dec 17 20:34:56 2014 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 269FE829 for ; Wed, 17 Dec 2014 20:34:56 +0000 (UTC) Received: from acipenser.esturion.net (acipenser.esturion.net [65.101.5.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EC5521864 for ; Wed, 17 Dec 2014 20:34:55 +0000 (UTC) Received: by acipenser.esturion.net (Postfix, from userid 112) id 85947260133; Wed, 17 Dec 2014 13:34:54 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on acipenser.esturion.net X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (quine.pinyon.org [65.101.5.249]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by acipenser.esturion.net (Postfix) with ESMTPSA id 61E01260051 for ; Wed, 17 Dec 2014 13:34:51 -0700 (MST) Message-ID: <5491E8EA.30902@pinyon.org> Date: Wed, 17 Dec 2014 13:34:50 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories References: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> <201412161337.58789.jhb@freebsd.org> <5490FB0A.9060702@pinyon.org> In-Reply-To: <5490FB0A.9060702@pinyon.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 20:34:56 -0000 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"