You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Lev Serebryakov <le...@FreeBSD.org> on 2014/10/20 16:41:00 UTC
svnadmin: E200002: Serialized hash missing terminator — but latest show revision is perfectly ok!
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I'm trying to recover SVN repository (which is mirror of other repo)
after (physical) server crash in process of "svnsync".
svnadmin verify gives me:
* Verifying metadata at revision 269998 ...
svnadmin: E200002: Serialized hash missing terminator
#
Please note, that 269998 is almost-round number. It is because I've
renmoved whole 270xxx range (latest one) of revisions (and their
properties) from repository, as them was synced in moment of crash. So,
all 269xxx revisions are OLD ones, which WAS NOT DAMAGED. I've checked
269998/269999 revisions properties — they are OK.
Is here any way to learn WHICH "Serialized hash" is damaged?! Why file
name is not included in error message?
- --
// Lev Serebryakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJURR78XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePHV8P/0niyPls9GNytVoaPIqfv5Tg
KeRaGct3l7NnsgsEY7OmkaqSdiXYJ8UWjak8so9OFVmrXHU5yi6fb/TkJSMMWWok
tzBmqXYsv2CEyX72vJNzMkxEykraug3kpioe1CX+6UqiqjKoYVanrbqMDcbhc2GN
W4rQGYuZ/U9Ek8HLBeVNvPAOzdtFThEDjgJTP2PokxqdA3cprPvVJyBE8Q2O3Dh7
QaQzbrHE4Bn7rxsJegdsWkiJldTnl2haKmqoOMWjPJmNTNShJlZs6di2ckoDDFwq
f64F5c9a/oHh7Wij+UKRdBikonSS76Tk3gLi26l50h8rNVylehjWBwaJg62w76ri
PL+3awviQNgscA1nr0BBIe12TFNvGxgGzdFPdjCQ2ru6OiRh1hHjOeQGmgNDEg3m
pz41mqcAUuHAPVo2mBQQIxv+iuLFHAlmFlCFIqiN2HypM5BNpno97Egz2UeyWbBN
MxKdrGVuWNAD7uOywmhMH/ymD4UURWg6dGwxraJGUQxV/6Xy7ETIyp38OxT+UEP5
jwBoRWWpphVa7ayc6F48Kb4FPtLRNAvZOnUe02u7x0UBLXCcIVFtKIFnLdZKGti7
+1+UWDPINsHcFtqLyISd4COvzVAcXRbW+BlgzTBcJXb/ZSn+0SRCy2Jh3ygaWzWa
sPXlYdqqFkB9lLsHWcBy
=NKU2
-----END PGP SIGNATURE-----
Re: svnadmin: E200002: Serialized hash missing terminator — but latest show revision is perfectly ok!
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Daniel Shahaf wrote on Wed, Oct 22, 2014 at 11:17:46 +0000:
> Stefan Sperling wrote on Mon, Oct 20, 2014 at 20:58:57 +0200:
> > On Mon, Oct 20, 2014 at 08:46:03PM +0200, Stefan Sperling wrote:
> > > On Mon, Oct 20, 2014 at 10:22:05PM +0400, Lev Serebryakov wrote:
> > > > -----BEGIN PGP SIGNED MESSAGE-----
> > > > Hash: SHA512
> > > >
> > > > On 20.10.2014 19:07, Stefan Sperling wrote:
> > > >
> > > > > I would recommend you reset the mirrored repository to the last
> > > > > known-good revision (269997?) by moving out of the way all files
> > > > > belonging to newer revisions (in db/revs) and revprops (in
> > > > > db/revprops), running 'svnadmin recover' (this should set
> > > > > db/current to the number of the last known-good revision)
> > > > I've done this three times, each time removing 100 revisions. Result
> > > > the same: before 2 revisions to end "svnadmmin verify" complains about
> > > > "Serialized hash missing terminator".
> > > >
> > > > Now 269999 is clear for sure, as it is very old revision. Iad. yes,
> > > > I've checked "revprops/269/269999", it is properly-formatted prop file.
> > > >
> > > > So, it is NOT problem of revprops, but it is about some other
> > > > (which?) file in repo.
> > >
> > > It's probably a corrupt entry in db/rep-cache.db which every sync
> > > keeps picking up again and again.
> > >
> > > Try the whole procedure again either with rep-sharing disabled
> > > in db/fsfs.conf (enable-rep-sharing = false), or with a copy
> > > of db/rep-cache.db from the master server which you should put
> > > in place before the 'svnadmin recover' step (because entries newer
> > > than the recovered HEAD revision are automatically removed from
> > > the rep-cache during 'svnadmin recover').
> >
> > Thinking about this some more, it's definitely safer to just
> > disable rep-sharing on the slave. Unless you have a bit-perfect
> > copy of the master repository on the slave it is probably unsafe
> > to copy rep-cache.db between repositories because revision files
> > on the slave might contain data in a different order, in which
> > case rep-cache entries copied from the master would be invalid.
> >
>
> Right, data from the master could be invalid for the slave because of
> different txn names, different zlib versions, or any number of other
> reasons.
>
> > If you really want to keep the rep-cache on the svnsync slave
> > you'd have to dump/load or sync again from r0 :-/
> > Or fiddle with the rep-cache sqlite table directly and remove
> > the bad entry (but you'd have to find that yourself).
> >
> > Disabling rep-caching is a perfectly safe thing to do.
> > It might cause the slave to use a little more diskspace than the
> > master does for future revisions, but there are no other downsides.
>
> Or you could delete rep-cache.db, that will keep rep-cache working,
> except that revisions younger than current HEAD will not participate
> in it.
>
s/younger/older/. (That is: new revisions will do rep-sharing only
amongst themselves, and will never references anything that is
in the rev files that already exist right now.)
Daniel
> Daniel
> (for the record: when backdating HEAD as recommended upthread, one
> should _always_ truncate or delete rep-cache.db too, to prevent
> corruption down the road from references into the "undone" revisions.)
Re: svnadmin: E200002: Serialized hash missing terminator— but latest show revision is perfectly ok!
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
> (for the record: when backdating HEAD as recommended upthread, one
> should _always_ truncate or delete rep-cache.db too, to prevent
> corruption down the road from references into the "undone" revisions.)
In 1.8 running "svnadmin recover" is better as it removes any references
to undone revisions but leaves those that are still valid:
http://subversion.tigris.org/issues/show_bug.cgi?id=4077
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svnadmin: E200002: Serialized hash missing terminator — but latest show revision is perfectly ok!
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Stefan Sperling wrote on Mon, Oct 20, 2014 at 20:58:57 +0200:
> On Mon, Oct 20, 2014 at 08:46:03PM +0200, Stefan Sperling wrote:
> > On Mon, Oct 20, 2014 at 10:22:05PM +0400, Lev Serebryakov wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA512
> > >
> > > On 20.10.2014 19:07, Stefan Sperling wrote:
> > >
> > > > I would recommend you reset the mirrored repository to the last
> > > > known-good revision (269997?) by moving out of the way all files
> > > > belonging to newer revisions (in db/revs) and revprops (in
> > > > db/revprops), running 'svnadmin recover' (this should set
> > > > db/current to the number of the last known-good revision)
> > > I've done this three times, each time removing 100 revisions. Result
> > > the same: before 2 revisions to end "svnadmmin verify" complains about
> > > "Serialized hash missing terminator".
> > >
> > > Now 269999 is clear for sure, as it is very old revision. Iad. yes,
> > > I've checked "revprops/269/269999", it is properly-formatted prop file.
> > >
> > > So, it is NOT problem of revprops, but it is about some other
> > > (which?) file in repo.
> >
> > It's probably a corrupt entry in db/rep-cache.db which every sync
> > keeps picking up again and again.
> >
> > Try the whole procedure again either with rep-sharing disabled
> > in db/fsfs.conf (enable-rep-sharing = false), or with a copy
> > of db/rep-cache.db from the master server which you should put
> > in place before the 'svnadmin recover' step (because entries newer
> > than the recovered HEAD revision are automatically removed from
> > the rep-cache during 'svnadmin recover').
>
> Thinking about this some more, it's definitely safer to just
> disable rep-sharing on the slave. Unless you have a bit-perfect
> copy of the master repository on the slave it is probably unsafe
> to copy rep-cache.db between repositories because revision files
> on the slave might contain data in a different order, in which
> case rep-cache entries copied from the master would be invalid.
>
Right, data from the master could be invalid for the slave because of
different txn names, different zlib versions, or any number of other
reasons.
> If you really want to keep the rep-cache on the svnsync slave
> you'd have to dump/load or sync again from r0 :-/
> Or fiddle with the rep-cache sqlite table directly and remove
> the bad entry (but you'd have to find that yourself).
>
> Disabling rep-caching is a perfectly safe thing to do.
> It might cause the slave to use a little more diskspace than the
> master does for future revisions, but there are no other downsides.
Or you could delete rep-cache.db, that will keep rep-cache working,
except that revisions younger than current HEAD will not participate
in it.
Daniel
(for the record: when backdating HEAD as recommended upthread, one
should _always_ truncate or delete rep-cache.db too, to prevent
corruption down the road from references into the "undone" revisions.)
Re: svnadmin: E200002: Serialized hash missing terminator — but latest show revision is perfectly ok!
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Oct 20, 2014 at 08:46:03PM +0200, Stefan Sperling wrote:
> On Mon, Oct 20, 2014 at 10:22:05PM +0400, Lev Serebryakov wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> >
> > On 20.10.2014 19:07, Stefan Sperling wrote:
> >
> > > I would recommend you reset the mirrored repository to the last
> > > known-good revision (269997?) by moving out of the way all files
> > > belonging to newer revisions (in db/revs) and revprops (in
> > > db/revprops), running 'svnadmin recover' (this should set
> > > db/current to the number of the last known-good revision)
> > I've done this three times, each time removing 100 revisions. Result
> > the same: before 2 revisions to end "svnadmmin verify" complains about
> > "Serialized hash missing terminator".
> >
> > Now 269999 is clear for sure, as it is very old revision. Iad. yes,
> > I've checked "revprops/269/269999", it is properly-formatted prop file.
> >
> > So, it is NOT problem of revprops, but it is about some other
> > (which?) file in repo.
>
> It's probably a corrupt entry in db/rep-cache.db which every sync
> keeps picking up again and again.
>
> Try the whole procedure again either with rep-sharing disabled
> in db/fsfs.conf (enable-rep-sharing = false), or with a copy
> of db/rep-cache.db from the master server which you should put
> in place before the 'svnadmin recover' step (because entries newer
> than the recovered HEAD revision are automatically removed from
> the rep-cache during 'svnadmin recover').
Thinking about this some more, it's definitely safer to just
disable rep-sharing on the slave. Unless you have a bit-perfect
copy of the master repository on the slave it is probably unsafe
to copy rep-cache.db between repositories because revision files
on the slave might contain data in a different order, in which
case rep-cache entries copied from the master would be invalid.
If you really want to keep the rep-cache on the svnsync slave
you'd have to dump/load or sync again from r0 :-/
Or fiddle with the rep-cache sqlite table directly and remove
the bad entry (but you'd have to find that yourself).
Disabling rep-caching is a perfectly safe thing to do.
It might cause the slave to use a little more diskspace than the
master does for future revisions, but there are no other downsides.
Re: svnadmin: E200002: Serialized hash missing terminator — but latest show revision is perfectly ok!
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Oct 20, 2014 at 10:22:05PM +0400, Lev Serebryakov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 20.10.2014 19:07, Stefan Sperling wrote:
>
> > I would recommend you reset the mirrored repository to the last
> > known-good revision (269997?) by moving out of the way all files
> > belonging to newer revisions (in db/revs) and revprops (in
> > db/revprops), running 'svnadmin recover' (this should set
> > db/current to the number of the last known-good revision)
> I've done this three times, each time removing 100 revisions. Result
> the same: before 2 revisions to end "svnadmmin verify" complains about
> "Serialized hash missing terminator".
>
> Now 269999 is clear for sure, as it is very old revision. Iad. yes,
> I've checked "revprops/269/269999", it is properly-formatted prop file.
>
> So, it is NOT problem of revprops, but it is about some other
> (which?) file in repo.
It's probably a corrupt entry in db/rep-cache.db which every sync
keeps picking up again and again.
Try the whole procedure again either with rep-sharing disabled
in db/fsfs.conf (enable-rep-sharing = false), or with a copy
of db/rep-cache.db from the master server which you should put
in place before the 'svnadmin recover' step (because entries newer
than the recovered HEAD revision are automatically removed from
the rep-cache during 'svnadmin recover').
Re: svnadmin: E200002: Serialized hash missing terminator — but latest show revision is perfectly ok!
Posted by Lev Serebryakov <le...@FreeBSD.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On 20.10.2014 19:07, Stefan Sperling wrote:
> I would recommend you reset the mirrored repository to the last
> known-good revision (269997?) by moving out of the way all files
> belonging to newer revisions (in db/revs) and revprops (in
> db/revprops), running 'svnadmin recover' (this should set
> db/current to the number of the last known-good revision)
I've done this three times, each time removing 100 revisions. Result
the same: before 2 revisions to end "svnadmmin verify" complains about
"Serialized hash missing terminator".
Now 269999 is clear for sure, as it is very old revision. Iad. yes,
I've checked "revprops/269/269999", it is properly-formatted prop file.
So, it is NOT problem of revprops, but it is about some other
(which?) file in repo.
- --
// Lev Serebryakov
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)
iQJ8BAEBCgBmBQJURVLNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF
QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePQX0P/iMBG5YljzcVMyk14YmW4Mkw
qeW9xRmOQFBiXt2Og9+kOIrsNgBCfhiRS3Wod8MqM7kpiPFPlYNCjzR9CztEZVyO
vYd4O6/s4dNfvYjvMrxsPymBl514kkzHlPfIAcCBrK/M/VbWIhHa5QO2TF2lQTDV
EmNhQHsao9EXyt5Ms2YYsx4ARohJvGdCllXUmuYwfvcQxL83O1/hhax1wQC/L+91
Tq/GiaLeXflT7+xAGNjFR7K/i8LpngTdSOlkEIONORu86xdcnyLKzYcCnJ3OTPif
sWmohTa0OC8V9cPUHY9QXosaWk7BKNkCFunIop5elmAYNFdk1+iVepf48JmDEjYp
rGA/ka/aFyrBCAY0mUG62j87sOnbHWqujDJ7oAM5cR4jBjRs5j+cLCrjIZpRfKat
sico48wwCBmZsvcc20jcvfcUlJOLoSotsxUKpFonzg+te2spHdI6N62rJ+QVI576
ntrjVOUEKk7Raih88oemEgBnXOiBFHcaAsAtKGLUw+OIOgR6LPtWwhR42pJYnuUp
RacMrZBz96m2iLVUxPgT67fHB6HvhjaShJU1HtmWTYoD7XwxJZvq/5l9eDY5JFGj
00lNb+MWuHhTFY1daD6T3Aqhe0rIGNbtQeD/br8bFXMr33YtxTspQKPkhw3+vmU/
BRBnIPLMLIpQvp9Vt6cZ
=49kb
-----END PGP SIGNATURE-----
Re: svnadmin: E200002: Serialized hash missing terminator — but latest show revision is perfectly ok!
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Oct 20, 2014 at 06:41:00PM +0400, Lev Serebryakov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
> I'm trying to recover SVN repository (which is mirror of other repo)
> after (physical) server crash in process of "svnsync".
>
> svnadmin verify gives me:
>
> * Verifying metadata at revision 269998 ...
> svnadmin: E200002: Serialized hash missing terminator
> #
>
> Please note, that 269998 is almost-round number. It is because I've
> renmoved whole 270xxx range (latest one) of revisions (and their
> properties) from repository, as them was synced in moment of crash. So,
> all 269xxx revisions are OLD ones, which WAS NOT DAMAGED. I've checked
> 269998/269999 revisions properties — they are OK.
>
> Is here any way to learn WHICH "Serialized hash" is damaged?! Why file
> name is not included in error message?
That serialised hash is inside a revprops file. You won't be able
to fix this directly unless you understand how FSFS stores data.
If you really want to know, start reading here:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_base/notes/structure
and then this:
https://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/structure
I would recommend you reset the mirrored repository to the
last known-good revision (269997?) by moving out of the way all files
belonging to newer revisions (in db/revs) and revprops (in db/revprops),
running 'svnadmin recover' (this should set db/current to the number
of the last known-good revision), and finally editing the
svn:sync-last-merged-rev revision property with
'svn pe -r0 --revprop REPOS_URL'
to write the number of the last known-good revision in there.
Now you should have a working repository that is synced up to the
last known-good revision and 'svnsync sync' should catch up again.