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

Re: FSFS7 repository corruption during commit with background upgrade

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Mon, 20 Oct 2014 15:32:32 +0200

On Tue, Sep 30, 2014 at 7:08 PM, Stefan Sperling <stsp_at_elego.de> wrote:

> On Tue, Sep 30, 2014 at 08:40:00PM +0400, Ivan Zhakov wrote:
> > I think there are the following viable options:
> > 1) make the svnadmin upgrade work properly for hot repositories
> > 2) do not enable log-addressing during svnadmin upgrade.
> >
> > I think (1) is almost impossible to implement since Subversion
> > does not use locks for read operations. I'm also think
> > that (2) is the best option in current situation. As an
> > additional bonus, it give us oportunity to remove some
> > tricky code like txn upgrade during commit.
> >
> > Btw the same approach was used in upgrade to FSFS
> > format 3 where sharded layout was introduced.
> >
> > Anyway I think it is a serious issue and any sort of
> > mention in the release notes will not solve it.
> +1
> This sounds sane.

As of r1631075, old servers are free to ignore the format
information when writing to the repository. In contrast to
the "any error could happen" approach of format 3, this
time, those servers get a variant of "ENOENT".

Read access to packed f7 revisions using f6 or earlier
would always fail with "ENOENT" due to the missing
manifest file. Read access to non-packed f7 revisions
fails with SVN_ERR_FS_CORRUPT.

That said, I still find it problematic to allow *writers* to
completely ignore the format info (this is what caching it
during an upgrade means). I'm not fully convinced that we
really always guarantee that under no circumstances any
harm could be done. Therefore, I would still add the warning
in the release notes.

-- Stefan^2.
Received on 2014-10-20 15:33:00 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.