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

Re: fsfs revprop packing in f5 Re: Does fsfs revprop packing no longer allow usage of traditional backup software?

From: Daniel Shahaf <danielsh_at_elego.de>
Date: Wed, 6 Jul 2011 20:20:03 +0300

Mark Phippard wrote on Wed, Jul 06, 2011 at 13:01:58 -0400:
> On Wed, Jul 6, 2011 at 12:47 PM, Daniel Shahaf <danielsh_at_elego.de> wrote:
> > This thread is now the only non-FSFS release blocker (filed as #3944).
> > Last I checked there were at least three solutions suggested, but no
> > consensus on which solution to implement.
> >
> > Some suggestions were
> >
> >
> > 0. Leave things as they are
> >
> > 1. Allow packing revisions without packing revprops.
> >   (revprops/ remains as in 1.6/f4)
> >
> > 2. Have all revprops in the DB all the time, never in plain files.
> >
> > 3. Swap the DB for some other "A thousand revision's revprops in one
> >   file" solution. [several suggestions as to that file's format]
> Should there be a new discussion about what is wrong with option 0?
> My recollection of the thread is that there were no issues raised that
> really "stuck". Meaning there was speculation and concern that turned
> out to be fairly manageable and a non-issue. So what is wrong with
> the current design approach?

What about your own answers to points (2) and (3)?

I'm not married to changing the format. But if there are good reasons
to do so --- whether they be "Easier for administrators" (Kevin's
original point) or "Easier for extension" (a property of Peter's
suggestion) --- now is the best time to do so, before we have to support
it, forever, while never blocking concurrent readers.

> My answers:
> 1) I always thought packing was pointless without packing revprops.
> You get the biggest win from the revprops.
> 2) I think this would be a terrible idea. Hot backup becomes nearly impossible.
> 3) As long as we had a good design, this would have been my
> preference.

Okay. Hyrum and I raised a few designs late on Friday, but I don't
recall discussion on which one was better.

> Mainly because I think adding SQLite adds some unknowns.
> However, given that rep sharing is there, I am not sure it matters at
> this point.

rep-cache.db isn't authoritative; it is consulted while writing the rev
files but never afterwards. revprops.db is authoritative (removing it
is comparable to deleting a rev file).

Apples and oranges.

> --
> Thanks
> Mark Phippard
> http://markphip.blogspot.com/
Received on 2011-07-06 19:20:54 CEST

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