[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Issue #4588, part 1: FSFS access error

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Sun, 23 Aug 2015 20:38:03 +0100

Garret Wilson had a terrible experience upgrading to SVN 1.9
(http://subversion.tigris.org/issues/show_bug.cgi?id=4588),
ranging from build problems over svnadmin load inconsistency
to a low-level FSFS format 7 read error.

This post focuses on the FSFS issue. The good news is that
confidence is high that the repo itself is correct and there
has been no apparent data loss. The error message indicates
that something like Offset=L2P[L2P[Item]] or Offset=L2P[Offset]
instead of Offset=L2P[item] happened.

Trying to reproduce the issue, I discovered bugs in our debug
logging code (only affects FSFS devs) and in svnfsfs load-index
(fix yet to be committed, work-around is possible). None of
these explain the behavior Garret has been seeing. I've also
been looking for places where svn_fs_fs__item_offset() gets
called but those invocations seem to never possibly do a
double lookup.

My current hypothesis is that the server did not get restarted
after replacing the repository. Because we decided not to make
the instance ID part of the cache key, we could easily have
picked up cached format 6 data for the format 7 repository.

The lookup would start with a hit at the L2 DAG cache, mapping
path+rev onto a noderev. From there, everything is accessed
using physical offsets until some item is not cached. At that
point, we would be trying to use an Offset instead of the Item
index to address the f7 data. Error.

-- Stefan^2.
Received on 2015-08-23 21:38:21 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.