[CentOS-devel] tracking ABI changes in C/C++ libraries

Thu Jul 22 23:12:31 UTC 2010
JohnS <jses27 at gmail.com>

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