Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 29 Jan 1998 19:13:53 +1100
From:      Bruce Evans <bde@zeta.org.au>
To:        bde@zeta.org.au, mike@smith.net.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:  <199801290813.TAA18259@godzilla.zeta.org.au>

next in thread | raw e-mail | index | archive | help
>> >> >  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.
>> >> ...
>> >> You could simply reject such transfers.
>> >
>> >And then what happens to them?  I spent some time trying to understand 
>> 
>> Nothing good.  
>
>Then why would rejecting the transfers be useful?

It wouldn't.
>
>> The driver strategy function may reduce the count
>> to whatever it wants.
>
>It was not clear that this was legitimate; I infer from this that the 
>correct approach is to return a nonzero value in b_resid, which will 
>cause another call to the strategy routine.  Is that correct?  Will 
>this work on 2.2?  It's certainly a *much* tidier approach than what I 
>am currently doing.

Only for raw i/o.  bread() and bwrite() don't even look at b_resid.
They depend on the initial count being smaller than MAXBSIZE (getblk()
enforces this by panicing if the count is larger), and on all drivers
not truncating counts smaller than this size or counts that would be
truncated not being used.

>Is this a lower-performance approach than queueing multiple ATAPI 
>requests?  Do we care about performance with such a slow device?

It's probably insignificantly lower-performance even on much faster
devices.

>> 	xx_bdevsw.d_maxio = <max i/o size in bytes>;
>> 
>> immediately after xx_bdevsw is initialized.
>
>... so you can't change it on the fly?  This is a serious defect.

Why would you want to change it?  You can probably change it, but
the changes won't affect queued requests.

Bruce



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199801290813.TAA18259>