Peter Samuelson wrote on Wed, Jul 06, 2011 at 15:10:15 -0500:
>
> [Hyrum K Wright]
> > Revprops wouldn't be packed until explicitly asked to do so by
> > 'svnadmin pack' which means the frequent post-commit revprop editing
> > wouldn't pose a performance problem.
>
> I still think it'd be possible, even practical, to create packfiles on
> the fly, instead of just explicitly via svnadmin pack. This requires
What do you gain by that?
> preallocating the 'manifest' region at the top of the file, to
> accommodate a full shard. And that in turn is easiest if manifest
> entries are fixed-width, say, 16 bytes, space-padded. (This limits us
> to 48-bit offsets. At 1000 revs per shard, you can average 256 GB of
> revprops per revision. Which is some distance into the realm of the
> ridiculous.)
>
> There is the question of atomicity of updates. But with the HEAD
> revision, note that nobody should be trying to read it until the commit
> is official! Therefore, assuming you hold a write lock, it should be
> perfectly safe to append the revprops to the pack file, then update the
> manifest entry, then release the write lock.
>
> Then we have the possibly common case of editing the HEAD revprops
> immediately after commit ... say, from post-commit hook. This can
> actually be special-cased, _because_ it is the HEAD rev:
>
> 0) Definitions: R0 = existing revprops blob, RN = new revprops blob
> 1) Rewrite R0 at offset R0 + max(len(R0), len(RN))
> 2) Rewrite R0 manifest entry
How do you rewrite the manifest entry atomically?
> 3) Write RN at offset R0
> 4) Rewrite RN manifest entry
> 5) Truncate file after RN
>
> This may seem to be a bit of work, but I bet it's not really
> noticeable. Plus, post-commit hook performance isn't nearly so
> important as performance of the rest of the system.
>
> Peter
Received on 2011-07-06 22:22:03 CEST