Date: Wed, 31 Mar 1999 21:26:33 -0700 (MST) From: "Justin T. Gibbs" <gibbs@narnia.plutotech.com> To: David Kelly <dkelly@HiWAAY.net> Cc: scsi@FreeBSD.org Subject: Re: cache and tape drives Message-ID: <199904010426.VAA43947@narnia.plutotech.com> In-Reply-To: <199904010246.UAA46365@nospam.hiwaay.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Have to admit CAM is over my head as I haven't found my answer. Haven't
> been sniffing around with a kernel debugger either. Suspect the ccb
> LINK and FLAG bits control the process blocking.
Not at all. Processes block on writes to all 'raw' devices. The
reason for this is simple. To avoid a copy of your data, the kernel
blocks your process, wires the data buffer in your process into memory
so it cannot be swapped out, and performs the I/O to the device. Only
once the I/O has completed can the call to write(2) complete to ensure
the proper semantics of the system call (e.g. you can reuse your buffer
as soon as write returns).
What you are seeing in your application is a classic latency problem.
You are transfering data between two high latency devices, so your
total throughput will suffer if you are only using a single process:
while (more_data) {
read from tape [block for a long while...]
write to tape [block for a long while...]
}
The write side likely has much less latency than the read side at
least until the write buffer in the device is filled. DDS-3 drives
do have a write buffer and the sa driver will make use of it. On
the read side, the tape driver must block until the data is available.
If the latency of transfering the read data into the write buffer
of the target tape device is large enough, you won't be able to
stream your reads, and performance will suffer.
So how do you solve the problem? For FreeBSD, you'll need to use
multiple processes to perform the reads and writes with some kind
of fast buffer in the middle. If a doesn't buffer enough data for
you, you can always allocate a piece of shared memory between the
two processes and make that as large as you like. With this kind
of strategy, you should be able to tune the appliation to the point
where your streaming read and write speeds are bounded by the speed
of the tape drives. In an ideal world, you could use async I/O
within a single application, but I haven't experimented enough
with AIO under FreeBSD to know if it is robust enough yet for
this task.
--
Justin
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904010426.VAA43947>