Date: Tue, 16 Dec 2014 20:39:54 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: freebsd-net@freebsd.org Subject: Re: compiling on nfs directories Message-ID: <5490FB0A.9060702@pinyon.org> In-Reply-To: <201412161337.58789.jhb@freebsd.org> References: <2048229686.13136235.1418677169130.JavaMail.root@uoguelph.ca> <201412161337.58789.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Happy holidays, and cheers! Russell
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5490FB0A.9060702>