Re: summer of code - scrub feature

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Sun, Mar 22, 2009 at 11:21:45PM +0000, Alistair Crooks wrote:
> 
> Yes, and there's the ability to have f?truncate(2) catered for by
> overwriting with random gibberish.
> 
> Oh, and not having to remember to specify -P to rm for any file that
> you want to make sure is overwritten, because it's too late once those
> data blocks make it back onto the freelist. I suppose you could take the
> hit and alias rm -P, and wait while directory trees take ages to delete.
> We're all too busy anyway, these days, and could do with a break.

There's another problem -- spared sectors.  There is a US Government
standard for erasing files and disks, which used to specify procedures
for securely erasing individual files.  That portion of the standard
was rescinded: for the government's purposes, anyway, only whole-disk
erase will suffice, and if the disk will not allow spared-out sectors
to be overwritten with the mandated erase patterns, even that is not
enough.

This is why I stopped improving rm -P after I read the _current_ 
version of the standard.  It is probably good enough, now, for most
people's purposes -- but it is _not_ good enough for the purposes of
those who care enough to do what the relevant standard says; and it
can't be.

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!

One project which would really be neat would be to make cgd use
opencrypto so that, on multicore hosts, its cryptography could happen
on whatever CPU had least to do.  Even laptops have two or four cores
or threads now!

Thor