This branch exists to reimplement the revprop-packing in FSFS f6 without SQLite. Several strategies have been discussed on the mailing list here: http://svn.haxx.se/dev/archive-2011-07/0134.shtml The concrete design proposal has been patched into the 'structure' file; you may review it via svn diff ^/subversion/trunk/subversion/libsvn_fs_fs/structure \ ^/subversion/branches/revprop-packing/subversion/libsvn_fs_fs/structure See issue #3944: http://subversion.tigris.org/issues/show_bug.cgi?id=3944 TODO: * add code catering for virus scanners during atomic move-into-place * implement per-shard locking + add sequence number; adjust readers accordingly * sync 'structure' with the implementation + manifest record alignment + manifest record width (bytes) * check for offset overflow (in manifest) * add some explicit tests for svnadmin upgrade/pack (both revs and revrops) * implement 'hotcopy' support (currently tests fail --- r1296975) * cf fs-successor-ids plans: Date: Fri, 26 Aug 2011 13:14:32 +0200 From: Stefan Sperling To: dev@subversion.apache.org Subject: FSFS successor ID design draft Message-ID: <20110826111432.GA8819@ted.stsp.name> Suggested: * each revprops blob should include its rev number, length, and checksum, prepended to the blob itself. (Or if it's awkward to prepend a checksum, put those things at the end, and omit the length as it is redundant by then.) * store edits in non-packed files * edit the revpack file in-place (requires aligning the manifest records to powers of 2) * multiple offsets per manifest record * append edits directly to the pack file, never have non-packed revprops * manifest offsets as s/ASCII/unserialized integers/ Wishlist or out-of-scope: * keep old revprop values for auditing * script to downgrade f5 to f4 * finer-grained (two-staged) locks for other operations (eg, packing revision shards) * cache some/all revprops in a pack file when reading it (see r1296604 thread) Not a problem: * ensure concurrent writers are not starved (Not more of a problem than it is with large commits today. Shouldn't be a problem in practice. Perhaps the antivirus retry logic will help, too.)