From owner-freebsd-bugs Wed Jun 19 05:52:50 1996 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA11513 for bugs-outgoing; Wed, 19 Jun 1996 05:52:50 -0700 (PDT) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA11501 for ; Wed, 19 Jun 1996 05:52:37 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id WAA16277; Wed, 19 Jun 1996 22:48:51 +1000 Date: Wed, 19 Jun 1996 22:48:51 +1000 From: Bruce Evans Message-Id: <199606191248.WAA16277@godzilla.zeta.org.au> To: gwk@cray.com, j@uriah.heep.sax.de Subject: Re: bin/1320: dump limits blocksize to 32K Cc: bde@zeta.org.au, freebsd-bugs@freefall.freebsd.org, gpalmer@FreeBSD.org Sender: owner-bugs@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk >> a) If physio() is broken for sizes > 64 kB, why doesn't the kernel >> return an error to the user if physio gets an I/O request > 64 kB? >It splits the request into 64 KB chunks, so it can handle them. This >works mostly except for tapes, which are IMHO the only devices that >might require a physical blocksize larger than 64 KB physio() needs to have a no-split flag that would be set by the tape drivers. >(raw SCSI >commands like WRITE BUFFER suffer from it as well). scsistrategy() has defense against splitting. It refuses to continue if the i/o size isn't the same as the original. st_strategy() might be able to use the same hack. It's not so easy since the original i/o size is in the uio struct and there may be multiple uio elements. Vectors of length 1 could probably be handled easily. Bruce