Re: File Corruption Problem on Unix

[Brian Robinson]

> 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
> option(s).
>
> 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
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs