"sanitizing" disks: wiping swap, non-allocated space, and file-tails

Brooks Davis brooks at one-eyed-alien.net
Fri Aug 13 22:09:06 PDT 2004


On Sat, Aug 14, 2004 at 05:45:08AM +0100, David Kreil wrote:
> 
> Dear Brooks,
> 
> > > > > > The easiest way to scrub a disk is:
> > > > > >
> > > > > > dd if=/dev/random of=/dev/<disk> bs=<sthg big>
> > > > > > <repeat a few times>
> > >
> > > I noticed that it will refuse to let me do that on swap, even if it is
> > > of f. Of course, I can edit the disklabel to read "unused", run dd, and
> > > restore the swap disklabel to "swap" but is there another way?
> > 
> > That's broken.  Which OS are you using?
> 
> Don't know whether I answered that before: 5.2.1-RELEASE-p9/GENERIC
> 
> To which list, if not fs, should I send a bug-report in your opinion?

It would help if you could test this under CURRENT.  The -geom list is
probably a good place to report this as it's probably a geom issue
(though it's possiably it's actually a swap issue).

> > > Also, I've just done some tests, and
> > >
> > >   dd if=/dev/random of=/dev/<mydisk> bs=1048576
> > >
> > > only writes at 6.5MB/s on my system (/dev/zero gives 7.9MB/s). Is that=20
> > > typical? My drives theoretically should do 30-40MB/s on read, and
> > > 20-30MB/s on write.
> > >
> > > If these results are "normal", however, that means, for a 10GB swap file
> > > and, say 6 wipes, I'd be waiting 3h on shutdown, while a BND-safe thorough
> > > 20 wipes would take half a day. Not really practical :-/
> > > So unless you tell me that I should be able to achieve much faster write
> > > speeds, I think I'll have to ditch the idea of regularly wiping swap (or
> > > anything else for that matter).
> 
> Actually, I just had one of the drives in my RAID replaced (which was 
> apparently on its way breaking down) and now get ~50MB/s write performance for 
> dd if=/dev/zero, and ~13MB/s for /dev/random. So if I could generate good 
> pseudo-random numbers fast enough, I should be able to wipe a 10GB partition 
> 20x in an hour - that's good enough!

The arc4random call will be good enough for most purposes, especially is
you reseed it before each run and discard the first 256 bytes.

> > If you
> > really want performance, you should use arc4random in a custom userland
> > program.  That's faster, but expect wiping a 40GB disk to take hours
> > even in that case.  I've got such an application, but I haven't had time
> > to clean it up and submit it for release.  I'll probably do it some day,
> > but I can't recommend waiting for that.  It's only about 800 lines of
> > code including the man page and a fancy composable operations system to
> > allow just about any DoD or non-DoD pattern or writes and verifies to be
> > written on the command line.
> 
> I'd be grateful if you could make your utility available. All I need
> is random patterns (white noise). Would that be possible at all,
> please?

My program can do that.  I'll see what I need to do to get it released.
It may take a little while.

-- Brooks

-- 
Any statement of the form "X is the one, true Y" is FALSE.
PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20040813/71358802/attachment.bin


More information about the freebsd-fs mailing list