info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

cvs as a heartbeat client (questions)


From: Todd Denniston
Subject: cvs as a heartbeat client (questions)
Date: Tue, 16 Mar 2004 11:43:49 -0500

I am setting up a new cvs server, and this one happens to be on a set of
machines using DRBD for disk mirroring and heartbeat for cluster management.

The two machines will share the same service DNS name (and IP), and which ever
of them is the current master will be the one with access to the file systems
on the DRBD devices. Our CVS repositories will be on one of the DRBD devices
using ext3 file systems.
BTW only the current master will be answering to the IP.

My questions:
1) does anyone in this group already have some scripts for nicely letting cvs
know it is about to lose it's lower level file systems, ready for calling in
the haresources file? (hey, had to ask :)

2) on linux will a `killall cvs` cause cvs (as server for :ext: &/or
:pserver:)to cleanup and exit nicely or is there a particular signal I should
pass to killall? What I want is to be able to essentially tell cvs is "I know
the file system is leaving, sync self and bail".

3) if a `killall cvs` is done on the the server processes what is the likely
output on a cvs client on a remote system? Will the client automatically try
again in a few seconds? Will it cause data corruption in the users sandbox?

4) worst case, if a user is committing and cvs is not stopped before the lower
level device goes away (probably from a power fail),  a partial or even full
',filename' new file could exist.
        a) correct???
        b) does anything need to be done in one of these worst cases, (re)move 
file?

5) is there a more efficient way of locking the repository than creating all
the `#cvs.rfl' in all the sub directories of all the repositories? That is, is
there a single file I can create that blocks access to each repo for the whole
repo, instead of what is suggested for backup?
http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_2.html#SEC24
Or should I temporarily change a soflink where the cvs bin is expected (this
could be problematic if someone has the bright idea of setting CVS_SERVER to
something else)?
I suppose unmounting the file system will also have a locking effect, but
there is a possible race between the killall and umount I think.

6) am I just over killing the effect removal of the disk from cvs will have on
the server processes?

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter




reply via email to

[Prev in Thread] Current Thread [Next in Thread]