Re: summer of code - scrub feature

[christos%astron.com@localhost (Christos Zoulas)]

In article <20090323012047.GA11291%panix.com@localhost>,
Thor Lancelot Simon  <tls%rek.tjls.com@localhost> wrote:
>On Mon, Mar 23, 2009 at 01:13:16AM +0000, Alistair Crooks wrote:
>> On Sun, Mar 22, 2009 at 08:07:06PM -0400, Thor Lancelot Simon wrote:
>>  
>> > The other problem is that the WAPBL journal will have pieces of file
>> > data in it.  Aggressively overwriting the log after transactions have
>> > been committed will _murder_ performance.  The best solution to all this
>> > is to just use cgd!
>> 
>> Requiring the use of cgd is certainly one way of addressing the
>> problem.  Another way would be to give up using computers completely
>> since we can never be sure that data will not be copied without our
>> prior knowledge and sent back to the HQ of the cabal's mothership.
>
>Let me try to state the actual performance constraints as I understand
>them, more succinctly:
>
>       1) Overwrite-on-erase for every erase will cost more than
>          encrypt-on-write for every write, on almost any modern
>          platform and for almost any workload.
>
>       2) WAPBL makes this even more so.  Much more so.
>
>       3) We expect that almost all users will use WAPBL for almost
>          all workloads.
>
>This suggests to me that cgd is always a better solution to the problem
>we are trying to solve here, that data might be read after files are
>erased.
>
>Morever, cgd ensures that you don't even have to worry about the journal
>or spared sectors.  It is a strictly better solution.

Thor is right here. Encrypting the data and writing it once is cheaper
than doing multiple writes to erase, easier than having to keep track
all the copies of the data that need erasing, and finally it solves the
problem of spared sectors.

christos