Hello David,
On Freitag, 6. Februar 2009, David Glasser wrote:
> That's a good write-up, but it doesn't handle the other big design
> decisions for obliterate: whether it's acceptable for the data to be
> reconstructible by somebody with direct access to the repository, and
> whether it's acceptable for space to not be reclaimed after
> obliterate.
>
> (For FSFS in particular, the answer to these questions hugely
> constrains implementation alternatives, since node IDs include the
> offset in a rev file.)
Of course, just changing a few pointers so that the obliterated data becomes
unreachable is fine as a fast operation that can be done while running
normally. (Apart from destroying some users' working copies, if they currently
have some to-be-obliterated data checked out, and where the next update would
[probably] result in wrong data.)
But I think there should be at least some way (eg. by using "svnadmin pack")
to reclaim the space.
Wiping the data (with a single pass of zeroes) might work for some people,
too, but as there's no easy way to punch holes in files (ie. make them sparse
in the middle) the space would be lost.
About the node IDs: How about some kind of "svnadmin pack -rX", that keeps all
offsets intact (to avoid having to change *a lot* of revisions), but skips
blocks where possible to make the file sparse? Sounds like an easy way for me.
Regards,
Phil
Received on 2009-02-06 07:48:53 CET