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

> Peter Samuelson wrote on Wed, Jul 06, 2011 at 15:10:15 -0500:
> > I still think it'd be possible, even practical, to create packfiles on
> > the fly, instead of just explicitly via svnadmin pack. This requires

[Daniel Shahaf]
> What do you gain by that?

The main thing you gain is a single code path for reading revprops.
This may come with some efficiency for reads, as well. (If there were
no efficiency gain for packed revprops, why would we have done it at
all?)

Of course, the single codepath is already not possible if we need to
support _optional_ revprop packing, and of course prior fsfs formats.

> > 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?

Whatever C99 or POSIX say, I don't see why write() of just a few bytes
would ever not be atomic. Especially if we choose 16 bytes, as that
will never cross a filesystem block boundary.

> > 3) Write RN at offset R0
> > 4) Rewrite RN manifest entry
> > 5) Truncate file after RN

It occurs to me, however, that step 5 might not be safe. There could
be an unbounded amount of time a reader caches a manifest entry before
trying to read the corresponding revprops entry. This might shoot down
my whole 5-step optimized rewrite of HEAD revprops in a packfile idea.

-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/