From owner-cvs-all Wed Jan 28 05:00:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA25564 for cvs-all-outgoing; Wed, 28 Jan 1998 05:00:23 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from word.smith.net.au (vh1.gsoft.com.au [203.38.152.122]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA25438; Wed, 28 Jan 1998 05:00:04 -0800 (PST) (envelope-from mike@word.smith.net.au) Received: from word (localhost [127.0.0.1]) by word.smith.net.au (8.8.8/8.8.5) with ESMTP id XAA01145; Wed, 28 Jan 1998 23:23:14 +1030 (CST) Message-Id: <199801281253.XAA01145@word.smith.net.au> X-Mailer: exmh version 2.0zeta 7/24/97 To: Bruce Evans cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, cvs-sys@FreeBSD.ORG, msmith@FreeBSD.ORG Subject: Re: cvs commit: src/sys/i386/isa wfd.c In-reply-to: Your message of "Wed, 28 Jan 1998 23:41:18 +1100." <199801281241.XAA05795@godzilla.zeta.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 28 Jan 1998 23:23:14 +1030 From: Mike Smith Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk > > Modified files: > > sys/i386/isa wfd.c > > Log: > > Fix operation with the Iomega Zip 100 ATAPI. > > All known versions of this drive (firmware 21.* and 23.*) will lock up > > if presented with a read/write request of > 64 blocks. In the presence > > of such a unit, I/O requests of > 64 blocks are fragmented to avoid > > this. > > > > Revision Changes Path > > 1.3 +92 -13 src/sys/i386/isa/wfd.c > > You could simply reject such transfers. And then what happens to them? I spent some time trying to understand what would happen if wfdstrategy (which I believe is being called via VOP_STRATEGY) rejected the transfer. Ultimately it was simpler to play scatter-gather with the bp and present an interface that looked like nothing had changed. POLA, etc. > The new d_maxio element in > struct bdevsw should limit clustering allow physio() to do the deblocking > for raw i/o. Nobody seems to call physio. And d_maxio isn't present in 2.2.*, while it was important that the fix be backportable. If d_maxio actually works (I recall John's commit implying that it wasn't completely done yet), then it would make sense to shift to using that for -current once we know that the fragmentation approach works. > Deblocking in the driver is only necessary for handling > > 32K filesystem blocks, which no one should want, especially on floppies. > It is only better if large i/o sizes are significantly more efficient. I actually thought I was on a winner setting D_NOCLUSTERRW in the bdevsw, but the msdosfs code reads in MAXPHYS slabs (I assume for its in-core copy of the FAT). I can assure you that if I thought there was a portable way to restrict the I/O size at a higher level I would take it. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\