From owner-freebsd-stable Tue Mar 2 18:13: 8 1999 Delivered-To: freebsd-stable@freebsd.org Received: from pop.uniserve.com (pop.uniserve.com [204.244.156.3]) by hub.freebsd.org (Postfix) with SMTP id 8CB7B1505E for ; Tue, 2 Mar 1999 18:13:06 -0800 (PST) (envelope-from tom@uniserve.com) Received: from shell.uniserve.ca [204.244.186.218] by pop.uniserve.com with smtp (Exim 1.82 #4) id 10I19S-0004Gc-00; Tue, 2 Mar 1999 18:12:46 -0800 Date: Tue, 2 Mar 1999 18:12:43 -0800 (PST) From: Tom X-Sender: tom@shell.uniserve.ca To: David Kelly Cc: freebsd-stable@FreeBSD.ORG Subject: Re: rc5des slows tape thruput In-Reply-To: <199903030125.TAA10091@nospam.hiwaay.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 2 Mar 1999, David Kelly wrote: > Tom writes: > > > The drive at home has 1M of internal RAM, the DDS-3 drives at work have > > > 2M buffers. It would appear FreeBSD doesn't make use of these buffers. > > > > I don't see how that could be. SCSI tapes are SCSI tapes. Any > > buffering done by the device should be invisible. There might be a SCSI > > mode page flag to turn it on or off though. > > What if you write 1MB ahead into the tape drive, then hit the end of > tape? How would one attempt to recover from that? It seems the Un*x > architects intend to be able to recover from that situation altho in > practice its unreliable. It seems only one block at a time is given to > the drive, and the drive doesn't ask for more until the first is safely > on tape. Well, that is assuming the buffer is used for writing. Tom To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message