[Top][All Lists]

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

Re: File Corruption Problem on Unix

From: Brian Robinson
Subject: Re: File Corruption Problem on Unix
Date: Wed, 14 Aug 2002 16:28:13 -0400

This doesn't sound like a CVS problem.

What you describe is extremely typical of what happens when a
UNIX system crashes while some program is actively creating or
deleting files.  It just happens that CVS does a lot of that, so
it's not surprising that many of the damaged files have CVS's
fingerprints all over them.  To blame it on CVS, though, is
likely a case of shooting the messenger.

Yes, that's been our experience, too.  It seems quite odd.

Why is the machine rebooting?  Is someone doing it on purpose, or
is it crashing?  If the latter, well, it shouldn't be; fixing
that will solve the supposed "CVS" problem too.

Agreed. In this case, we had a power failure in the area that crashed all of our servers without battery backup (this was one of them). So it indeed did not come down gracefully. However, our other unix servers that came down all came up without a hitch yesterday. We investigated this path a little more a few weeks ago -- running some CVS activity, then rebooting with "init 0", then "boot". It resulted in the same kinds of problems

Based on your comments, it might be more prudent to bring down the CVS server gracefully before doing a planned reboot.

If it is a purposeful reboot, how is this being accomplished?  If
with "reboot -n" or "-q", there's your problem; get rid of the

When is the machine rebooting?  If it's shortly after someone ran
one of those CVS-related commands, all these problems are to be
expected (well, depending on the answers to the questions in the
previous paragraph :-)

There was nothing active at the time. The files impacted were created over the past month. We were able to trace them to specific CVS activities (scripts) that ran then (based on timestamps on script output and the lost+found files created). (yes, yes, I know CVS may just be the messenger... =)

If it's a long time after, something else is going on -- the data
should have been flushed to disk by then; that it hasn't been
suggests yet another problem.  (What's the cutoff?  A few seconds
is "shortly"; several minutes is "a long time".  I don't know
enough to pin it down more precisely; someone who knows Solaris
better than I do will have to speak to that.)


|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Anyone who swims with the current will reach the big music steamship;
whoever swims against the current will perhaps reach the source.
        - Paul Schneider-Esleben

Info-cvs mailing list

reply via email to

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