From owner-freebsd-arch Sat Feb 3 13: 4:16 2001 Delivered-To: freebsd-arch@freebsd.org Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 30CD037B401; Sat, 3 Feb 2001 13:03:59 -0800 (PST) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.0/8.9.3) with ESMTP id f13L3nO55354; Sat, 3 Feb 2001 14:03:50 -0700 (MST) (envelope-from gibbs@scsiguy.com) Message-Id: <200102032103.f13L3nO55354@aslan.scsiguy.com> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Matt Dillon Cc: Mike Smith , Dag-Erling Smorgrav , Dan Nelson , Seigo Tanimura , arch@FreeBSD.ORG Subject: Re: Bumping up {MAX,DFLT}*PHYS (was Re: Bumping up {MAX,DFL}*SIZ in i386) In-Reply-To: Your message of "Wed, 31 Jan 2001 14:08:29 PST." <200101312208.f0VM8Tm17958@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 03 Feb 2001 14:03:49 -0700 From: "Justin T. Gibbs" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > And, finally, while large I/O's may seem to be a good idea, they can > actually interfere with the time-share mechanisms that smooth system > operation. Large I/Os, while interesting for disks, are often *required* for dealing with non-disk devices. If I want to read a tape generated from an SGI, for example, the records may be 1MB in size. Almost all of our PCI SCSI controllers can perform such a large I/O, but DFLTPHYS prevents you from servicing such an I/O. On devices like tape, you can't break up the I/O to the device into chunks smaller than the block size. We *need* a way to perform I/Os that span more than one buffer so we can avoid the DFLTPHYS limit. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message