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

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 19:47:23 +0300

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]

Can we decide on what to do here?

Thanks,

Daniel

---------

My opinion:

* (1) is orthogonal to the others, but may be a good idea if we refactor
  the FS so shortly before the release

* (2) simplifies things, doesn't solve the problems with having an
  SQLite db authoritative for parts of the FS storage
  (read: cp(1) unsafe)

* (3) has my +1, assuming it's sufficiently performant and the concrete
  design is reasonable

* (0) would mean that if we refactor revprop storage later, 1.8 servers
  will have to try and read revprops from *three* places; and lots of
  headache in the upgrade (and read-from-a-being-upgraded-FS) codepaths.
  So, if f5 should be improved, I'd rather do that /before/ it's
  released (and has to be indefinitely supported).
Received on 2011-07-06 18:48:17 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.