getting garbage faster using FreeBSD?

Kris Kennaway kris at obsecurity.org
Mon Feb 19 21:25:35 UTC 2007


On Mon, Feb 19, 2007 at 10:09:50PM +0100, Volker wrote:
> On 02/19/07 20:51, Kris Kennaway wrote:
> > On Mon, Feb 19, 2007 at 08:40:37PM +0100, Volker wrote:
> >> The tape sits there since 48 hours writing a block of data every
> >> other minute and still didn't fill up the tape completely. The
> >> system this is running on is a P-4 3GHz machine using FreeSBIE 2.0
> >> (6.2-RELEASE based).
> >>
> >> I suspect this to be a slow /dev/random.
> > 
> > This sounds odd to me, I get 18-20MB/sec sustained read performance
> > from /dev/random on this 2GHz system, which is probably faster than
> > your tape write speed.
> 
> Hmm, so this might be the tape drive(r)? I'll check this out as soon
> as I'm going to write to hard disk.
> 
> I'm going to make some tests with /dev/random to get the real speed.

Yes, it could be - you should do some more tests to find out where
your bottleneck really is before trying to possibly optimize the wrong
thing.

> >> Is there any chance to speed up /dev/random? Would a hifn
> >> accelerator card help here to get FreeBSD produce garbage faster?
> >>
> >> As there is medical data on all media I really need garbage
> >> (/dev/zero wouldn't be enough for data security as this might get
> >> recovered).
> > 
> > Neither would a single pass with /dev/random, but you presumably knew
> > this.
> 
> Yes, I know... I would like to run 5 or more passes if it's not that
> slow.
> 
> Do you think playing with randoms' sysctl interface might influence
> performance? Does /dev/random automatically re-seed from time to
> time or is it seeded at boot time only?

It re-seeds continuously, see random(4) and/or the yarrow
specification.  Don't frob the sysctls until you have confirmed that
/dev/random is really your problem though.

Kris


More information about the freebsd-stable mailing list