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

Re: [RFC] Obliterate - FS transaction design

From: Hyrum K. Wright <hyrum_at_hyrumwright.org>
Date: Wed, 23 Sep 2009 09:40:12 -0400

On Sep 23, 2009, at 9:35 AM, Julian Foad wrote:

> On Wed, 2009-09-23 at 09:30 -0400, Hyrum K. Wright wrote:
>> On Sep 22, 2009, at 3:02 PM, Daniel Shahaf wrote:
>>
>>> Philipp Marek wrote on Tue, 22 Sep 2009 at 15:15 +0200:
>>>> Should be "easy" to do for BDB (for some values of "easy" ;-); in
>>>> FSFS you
>>>> might have to rewrite the revs/ file, but with a hole where deleted
>>>> contents
>>>> have been, so that the file positions stay the same.
>>>>
>>>> (AFAIK addressing of content across revisions is done via byte
>>>> positions,
>>>> isn't it?)
>>>
>>> I don't know how addressing inside a rev file works. But addressing
>>> a rev
>>> file inside a pack file *is* done via byte offsets (i.e., we store
>>> in the
>>> manifest file the offset of the rev file within the pack file; the
>>> pack
>>> file is a straight concatenation of rev files).
>>
>> Intra-revision references are stored using byte offsets, so you'd
>> either have to rewrite all existing references (hard) or fill the
>> deleted hole with empty space (easy). Ignoring various operating
>> system tricks for storing zero-filled sectors, the second option
>> doesn't provide any of the space savings that obliterate is intended
>> for.
>
> Obliterate is intended for more than one thing. Space saving is one of
> them. Hiding sensitive data is another.

Sure. I didn't mean to imply that obliterate is only intended for
space saving, simply that our FSFS reference mechanism might make
achieving that particular goal a bit tricky. Sorry for any confusion.

-Hyrum

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2398887
Received on 2009-09-23 15:40:27 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.