In response to Volker <firstname.lastname@example.org>:
> 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.
Are you actually using /dev/random and not /dev/urandom?
/dev/random is "military grade" random data. It will block if it feels
that it hasn't gathered enough entropy to satisfy your request. It will
never provide random data at any reasonable speed, but it will provide
high-quality random data.
If you need lost of random data, use /dev/urandom, which provides data
that _may_ be predictable under some circumstances, but will provide
it at a decent rate of speed.
> >> Is there any chance to speed up /dev/random? Would a hifn
> >> accelerator card help here to get FreeBSD produce garbage faster?
Have you taken a look at DBAN for the drives? I don't know if DBAN
will work on the tapes, though.
> >> 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
> 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?
Collaborative Fusion Inc.