FSFS "read length line" repository corruption -- still not fixed in 1.4.2

Dear Subversion Users and Developers,

Sorry for the cross-post, but I think that this problem requires more
attention, than it has received in the past.

This is the famous "read length line" error, which can be fixed (in some
situation) by John Szakmeister's also famous fsfsverify.py.

The problem is that because of the nature of the bug (for a detailed
description please look at http://svn.haxx.se/dev/archive-2006-02/0473.shtml
) it is not easy for the developers to reproduce the issue.

Now with the release of the SVN 1.4.2 the developers believed that this
issue was fixed.

Unfortunately I can confirm, that this is not the case.

At our server the configuration is as follows:
Debian Sarge
libdb4.4 -- from backports.org
Apache 2.0.54 -- custom built debian package, includes APR 0.9.13 and
compiled for libdb4.4
Subversion 1.4.2 -- custom built debian package (backport by the SVN
maintainer of Debian; rebuilt for APR 0.9.13 and libdb4.4)

The system is used exclusively over https using mod_dav_svn repository
access method.

I used custom built packages because:
- I read that the APR 0.9.6, which is included with apache 2.0.54 does not
report errors on buffered streams, and that this behaviour was fixed in
0.9.7 and later. It was suggested in the list archives that this could
increase the possibility of this bug.
- libdb4.4 includes those new APIs, which enable Subversion to automatically
recover BDB repositories from an inconsistent state.

Currently all of our repositories are in the FSFS format, with daily
automated "svnadmin verify". The usage patterns of our repositories include
the checkins of some fairly large files (10-50MB).

I think I have done anything to minimise the risks, but I would like to make
sure that:
-this issue receives greater publicity: the Subversion Development Team
should release an advisory about this issue with suggested workarounds)
-it gets fixed in the foreseeable future.

I would also ask the SVN developers about the suggested course of action.

Right now I see two alternatives:
1. convert all repositories to BDB and deal with the issues of BDB (library
upgrades, possible corruptions at file system full, backup)
2. install a post-commit hook script to check each revision after the commit
and send a mail to the admins / who checked in that the revision is corrupt.

Are there other possibilities? (No, switching to a different RA method is
not an option)

Best Regards,
Gergely

PS: I looked at the CHANGES file in 1.4.3, but I did not see a fix relevant
to this issue.
Received on Tue Jan 30 12:12:41 2007