Date: Thu, 30 May 1996 21:27:05 +0200 (MET DST) From: Wilko Bulte <wilko@yedi.iaf.nl> To: bde@zeta.org.au (Bruce Evans) Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: removing 32 kbyte limit from dump Message-ID: <199605301927.VAA08360@yedi.iaf.nl> In-Reply-To: <199605301219.WAA19690@godzilla.zeta.org.au> from "Bruce Evans" at May 30, 96 10:19:02 pm
next in thread | previous in thread | raw e-mail | index | archive | help
As Bruce Evans wrote...
>
> >But I'm not really satisfied by this. I'd rather see that the st.c
> >driver returns EINVAL or something like that when an attempt is made
> >to write an impossible block size (and of course dump should act
> >accordingly when it receives the error value).
>
> 96K is not impossible. It just gets mutilated to 64K+32K by physio(),
Read impossible as: as the physio() code now handles it.
> and the error isn't detected because both 64K and 32K are possible.
> physio() needs to have a do-not-split flag.
Hm.
> Similar problems probably affect cd and worm devices. An i/o of
> 100 * 2352 byte blocks would be mutilated at 64K boundaries. This
> can be fixed using the current physio() interface: don't use rawread()/
> rawwrite(), and provided a minphys() function that returns
> (MAXPHYS / 2352) * 2352 (it must be <= MAXPHYS because physio()
> uses min(MAXPHYS, minphys()).
For cd this is possible not a big problem. I'm not sure about worm.
> >! /* so lets tell the user now and not wait for him/her
> >! /* to see the console message */
> >! if ( ntrec > 64 ) {
> >! msg("Please choose a blocksize <= 64 \n");
> > exit(X_ABORT);
>
> 64 should be MAXPHYS/1024.
True!
Wilko
_ __________________________________________________________________________
| / o / / _ Wilko Bulte email: wilko@yedi.iaf.nl
|/|/ / / /( (_) Private FreeBSD site - Arnhem - The Netherlands
--------------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199605301927.VAA08360>