On Thu, 2010-07-22 at 15:30 -0400, R P Herrold wrote: > > On 07/20/2010 02:35 PM, JohnS wrote: > NFS locking, and delay, and clock skew issues on the NFS > servers vs. the build unit, make building in an NFS mount a > painful experience. Adding chroot just makes what needs to be > a robust process more fragile I agree in one way then the other I do not. Standard kernel I see problems of timing issues. On the other hand a very different kernel, lets just say you can heartbeat to tier1atomic clock. Standard CentOS pool uses 2 which means the end user host is 3. I actually use that same kernel you seen on a host that's tier 2 clock. The killer is not the machine itself. It is the latency of the network. I can say as of now no time stamp problem yet (knock on wood). You know it's like the stock market. Latency loses all the time. As for the total chroot that's in the back of my mind and no frilies on it yet. I don't have good thoughts on that. I started a local disk chroot to build a specific yonder project to see if it would return me repetable results under CentOS. I think a bot picked that up somewhere. > There is little percentage to nfs based build finesystems, > unless it is one's only choice ... and with the way ram prices > have moved in the last few years, tmpfs provides a clearly > better choice --- NFS exported to me running on my storage server give me multiple redundant data copies. temp fs scares me unless I have a machine capable of RAM RAID 1 + Multi ECC and I have only one atm. It would be a much better way, I can't argue that point. John