[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: File Corruption Problem on Unix
From: |
Eric Siegerman |
Subject: |
Re: File Corruption Problem on Unix |
Date: |
Wed, 14 Aug 2002 15:40:25 -0400 |
User-agent: |
Mutt/1.2.5i |
On Wed, Aug 14, 2002 at 01:27:52PM -0400, Brian Robinson wrote:
> Has anyone experienced or heard of the following problem:
>
> - First we are running CVS 1.11 on Solaris 2.8
> - Desktop checkin/checkout through WinCVS works great
> - Unix checkin/checkout results in problems that show up as file corruption
> on a machine reboot. We're trying to pinpoint the commands that might be
> causing the problem, but here is what we've found so far:
> -- we run some combination of "cvs export -r tag", "cvs checkout module",
> plus "rm -R *" commands to clean out the working directories.
> -- The next time our Solaris machine reboots, it reports file corruptions
> that must be cleaned up with fsck.
> -- The fsck activity results in a bunch of lost+found files being created
> with the timestamp and permissions of the user who was doing the cvs work.
> -- The contents of the lost+found files look like CVS controls information.
> --- Example: A lot of files contain the strings "Entries",
> "Entries.log",
> "Repository", "Root"
> --- Example: Other files contain list of files in a given directory in
> the
> repository
> -- The CVS repository seemed unaffected by these problems -- it's come back
> clean every time
> -- Some of the file corruption occurs on the boot drive of the unix
> machine. We need to clean it up first, then clean up the problems on the
> filesystem that houses CVS and the CVS work directories.
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.
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.
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 :-)
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