You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by D D <dd...@gmail.com> on 2012/01/11 12:51:32 UTC
'svnadmin verify' failed after hotcopy with 'svnadmin: E160004:
Revision file (r2255) lacks trailing newline'
Hi,
My svn backup script calls:
- svnadmin hotcopy
- svnadmin verify (on the copy)
Once (for now) the verify call failed with 'svnadmin: E160004: Revision
file (r2255) lacks trailing newline'
The copy of the repository is still available and I can reproduce the
problem.
The subsequent hot copies of the same repository are ok (for now).
Is it ok to file this as a hotcopy bug, please?
The server is VisualSVN 2.5.2 (Subversion 1.7.2) on WinXP SP3.
Thanks,
Dmitry
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin: E160004: Revision file (r2255) lacks trailing newline'
Posted by Philip Martin <ph...@wandisco.com>.
D D <dd...@gmail.com> writes:
> I'd be interested to know if svnadmin employs some memory buffer to
> hot-copy.
> The offsets where data corruption starts look like multiples of 0x1000
> which is 4K.
> The NTFS cluster size on the disk is exactly 4K.
> If svnadmin just calls the OS to copy each file the problem should either
> be in the OS
> or the disk.
Hotcopy uses libsvn_subr/io.c:copy_contents where SVN__STREAM_CHUNK_SIZE
is 16384:
/* Copy bytes till the cows come home. */
while (1)
{
char buf[SVN__STREAM_CHUNK_SIZE];
apr_size_t bytes_this_time = sizeof(buf);
apr_status_t read_err;
apr_status_t write_err;
/* Read 'em. */
read_err = apr_file_read(from_file, buf, &bytes_this_time);
if (read_err && !APR_STATUS_IS_EOF(read_err))
{
return read_err;
}
/* Write 'em. */
write_err = apr_file_write_full(to_file, buf, bytes_this_time, NULL);
if (write_err)
{
return write_err;
}
if (read_err && APR_STATUS_IS_EOF(read_err))
{
/* Return the results of this close: an error, or success. */
return APR_SUCCESS;
}
}
--
Philip
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin: E160004:
Revision file (r2255) lacks trailing newline'
Posted by David Chapman <dc...@acm.org>.
On 1/12/2012 4:51 AM, D D wrote:
> On Thu, Jan 12, 2012 at 3:41 PM, Andy Levy <andy.levy@gmail.com
> <ma...@gmail.com>> wrote:
>
> Have you run svnadmin verify against the *actual* repository?
>
>
> Yes. No problem detected.
>
> If you make a new hotcopy of the repository, is that corrupted as
> well?
>
>
> No. I've only got a corrupted hot copy once in the last two weeks
> (backups are daily).
> Before that the repository was hosted on another WinXP system with
> an earlier version of the Subversion server. I only added the call to
> verify
> the hot copy to the backup script recently so I do not know if the problem
> ever occurred with the repository on the other system.
>
> I'd be interested to know if svnadmin employs some memory buffer to
> hot-copy.
> The offsets where data corruption starts look like multiples of 0x1000
> which is 4K.
> The NTFS cluster size on the disk is exactly 4K.
> If svnadmin just calls the OS to copy each file the problem should
> either be in the OS
> or the disk.
This really, really, really looks like a hardware problem or an
OS-related corruption. I agree with Andy Levy - Windows XP is not a
good OS to use as a server; it's 10 years old and they still haven't
bothered to fix bugs that I can invoke on a daily basis (most commercial
backup programs will cause a Windows service to go into an infinite loop).
Upgrade if you possibly can. Linux is free and runs on cheap hardware,
so I recommend it rather than try to find a Windows version that is
inexpensive but can still act as a server.
The fact that the problem is intermittent also points to something
outside of Subversion.
--
David Chapman dcchapman@acm.org
Chapman Consulting -- San Jose, CA
Software Development Done Right.
www.chapman-consulting-sj.com
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin:
E160004: Revision file (r2255) lacks trailing newline'
Posted by Daniel Shahaf <da...@elego.de>.
D D wrote on Thu, Jan 12, 2012 at 16:51:06 +0400:
> I'd be interested to know if svnadmin employs some memory buffer to
> hot-copy.
subversion/libsvn_fs_fs/fs_fs.c svn_fs_fs__hotcopy()
(The code may differ significantly between version -- check the sources
of the version of libsvn_fs_fs your svnadmin uses)
Daniel
(no time, sorry)
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin: E160004:
Revision file (r2255) lacks trailing newline'
Posted by D D <dd...@gmail.com>.
On Thu, Jan 12, 2012 at 3:41 PM, Andy Levy <an...@gmail.com> wrote:
> Have you run svnadmin verify against the *actual* repository?
Yes. No problem detected.
> If you make a new hotcopy of the repository, is that corrupted as well?
>
No. I've only got a corrupted hot copy once in the last two weeks (backups
are daily).
Before that the repository was hosted on another WinXP system with
an earlier version of the Subversion server. I only added the call to
verify
the hot copy to the backup script recently so I do not know if the problem
ever occurred with the repository on the other system.
I'd be interested to know if svnadmin employs some memory buffer to
hot-copy.
The offsets where data corruption starts look like multiples of 0x1000
which is 4K.
The NTFS cluster size on the disk is exactly 4K.
If svnadmin just calls the OS to copy each file the problem should either
be in the OS
or the disk.
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin: E160004:
Revision file (r2255) lacks trailing newline'
Posted by Andy Levy <an...@gmail.com>.
List convention is to not top-post.
On Thu, Jan 12, 2012 at 04:40, D D <dd...@gmail.com> wrote:
> Daniel,
>
> Is your answer based on the knowledge of the code of the subversion server?
>
> Here are some details:
> 1. It is not Unix [cp(1)], the problem was on Windows
> 2. The disk looks fine (I ran chkdsk and looked at the SMART data). No
> errors in the Windows log files.
> 3. The svn repository did not change since the problem was detected and I
> compared the corrupt hot copy to a correct one. There are 7940 files in
> each. Of these, the contents of 28 files are not the same (file sizes are
> ok). These 28 files are of various sizes but the first one (2255) is rather
> large - 1.5 MB. The repository size is about 1GB. The data in the rev files
> of the bad copy is corrupted from positions 0x1000 (first and second file),
> 0x4000, 0, 0x1000, 0, 0, 0x4000, 0, 0, 0, 0x4000 etc. The corrupted file
> numbers are not sequential (2255 corrupted, 2256-2270 ok, 2271 corrupted).
> 4. Some antivirus software is running on the system.
> 5. The 'svnadmin hotcopy' which produced the corrupt copy returned 0
> (success) to the script that called it.
> 6. The system might have been heavily loaded at the time the corrupt copy
> was made.
>
> It looks unlikely that 28 files were corrupted and no errors were logged by
> the OS.
> Do you still think is was a disk issue?
>
> Thanks,
> Dmitry
>
> PS The server is VisualSVN 2.5.2 (Subversion 1.7.2) on WinXP SP3.
It is still possible that you have disk corruption which couldn't be
detected by the host OS or physical disk monitoring (SMART).
Have you run svnadmin verify against the *actual* repository? If you
make a new hotcopy of the repository, is that corrupted as well?
IMHO if your "server" is running XP SP3, you don't *really* have a
server. You have a desktop which is pretending to be a server, and it
may not be as reliable as a true server. Especially under stress. For
something as important as your VCS system, you need server-grade
hardware and a server-grade OS.
> On Wed, Jan 11, 2012 at 6:52 PM, Daniel Shahaf <da...@elego.de> wrote:
>>
>> D D wrote on Wed, Jan 11, 2012 at 15:51:32 +0400:
>> > Once (for now) the verify call failed with 'svnadmin: E160004: Revision
>> > file (r2255) lacks trailing newline'
>> > The copy of the repository is still available and I can reproduce the
>> > problem.
>> > The subsequent hot copies of the same repository are ok (for now).
>> >
>> > Is it ok to file this as a hotcopy bug, please?
>> >
>>
>> No. All 'hotcopy' does is copy the revisions files using the same means
>> cp(1) uses. I'd check the health of your disks or replace them.
>
>
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin: E160004:
Revision file (r2255) lacks trailing newline'
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
On Thu, Jan 12, 2012, at 13:40, D D wrote:
> Daniel,
>
> Is your answer based on the knowledge of the code of the subversion server?
>
Yes
> Here are some details:
> 1. It is not Unix [cp(1)], the problem was on Windows
> 2. The disk looks fine (I ran chkdsk and looked at the SMART data). No
> errors in the Windows log files.
> 3. The svn repository did not change since the problem was detected and I
> compared the corrupt hot copy to a correct one. There are 7940 files in
> each. Of these, the contents of 28 files are not the same (file sizes are
> ok). These 28 files are of various sizes but the first one (2255) is rather
> large - 1.5 MB. The repository size is about 1GB. The data in the rev files
> of the bad copy is corrupted from positions 0x1000 (first and second file),
> 0x4000, 0, 0x1000, 0, 0, 0x4000, 0, 0, 0, 0x4000 etc. The corrupted file
> numbers are not sequential (2255 corrupted, 2256-2270 ok, 2271 corrupted).
I don't understand. Anyway: after a hotcopy, the revs/ and revprops/
trees of the source/dest of the hotcopy will be BYTE FOR BYTE IDENTICAL.
(If you commit while a hotcopy is running, the commit may or may not be
included in the copy, but the destination's integrity is guaranteed
anyway and all other revision files will be identical still.)
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin: E160004:
Revision file (r2255) lacks trailing newline'
Posted by D D <dd...@gmail.com>.
Daniel,
Is your answer based on the knowledge of the code of the subversion server?
Here are some details:
1. It is not Unix [cp(1)], the problem was on Windows
2. The disk looks fine (I ran chkdsk and looked at the SMART data). No
errors in the Windows log files.
3. The svn repository did not change since the problem was detected and I
compared the corrupt hot copy to a correct one. There are 7940 files in
each. Of these, the contents of 28 files are not the same (file sizes are
ok). These 28 files are of various sizes but the first one (2255) is rather
large - 1.5 MB. The repository size is about 1GB. The data in the rev files
of the bad copy is corrupted from positions 0x1000 (first and second file),
0x4000, 0, 0x1000, 0, 0, 0x4000, 0, 0, 0, 0x4000 etc. The corrupted file
numbers are not sequential (2255 corrupted, 2256-2270 ok, 2271 corrupted).
4. Some antivirus software is running on the system.
5. The 'svnadmin hotcopy' which produced the corrupt copy returned 0
(success) to the script that called it.
6. The system might have been heavily loaded at the time the corrupt copy
was made.
It looks unlikely that 28 files were corrupted and no errors were logged by
the OS.
Do you still think is was a disk issue?
Thanks,
Dmitry
PS The server is VisualSVN 2.5.2 (Subversion 1.7.2) on WinXP SP3.
On Wed, Jan 11, 2012 at 6:52 PM, Daniel Shahaf <da...@elego.de> wrote:
> D D wrote on Wed, Jan 11, 2012 at 15:51:32 +0400:
> > Once (for now) the verify call failed with 'svnadmin: E160004: Revision
> > file (r2255) lacks trailing newline'
> > The copy of the repository is still available and I can reproduce the
> > problem.
> > The subsequent hot copies of the same repository are ok (for now).
> >
> > Is it ok to file this as a hotcopy bug, please?
> >
>
> No. All 'hotcopy' does is copy the revisions files using the same means
> cp(1) uses. I'd check the health of your disks or replace them.
>
Re: 'svnadmin verify' failed after hotcopy with 'svnadmin:
E160004: Revision file (r2255) lacks trailing newline'
Posted by Daniel Shahaf <da...@elego.de>.
D D wrote on Wed, Jan 11, 2012 at 15:51:32 +0400:
> Once (for now) the verify call failed with 'svnadmin: E160004: Revision
> file (r2255) lacks trailing newline'
> The copy of the repository is still available and I can reproduce the
> problem.
> The subsequent hot copies of the same repository are ok (for now).
>
> Is it ok to file this as a hotcopy bug, please?
>
No. All 'hotcopy' does is copy the revisions files using the same means
cp(1) uses. I'd check the health of your disks or replace them.