Date: Wed, 28 Jan 1998 23:23:14 +1030 From: Mike Smith <mike@smith.net.au> To: Bruce Evans <bde@zeta.org.au> 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 Message-ID: <199801281253.XAA01145@word.smith.net.au> In-Reply-To: Your message of "Wed, 28 Jan 1998 23:41:18 %2B1100." <199801281241.XAA05795@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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. \\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801281253.XAA01145>