From owner-freebsd-bugs  Mon Jun 17 22:52:47 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA01724
          for bugs-outgoing; Mon, 17 Jun 1996 22:52:47 -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 WAA01710
          for <freebsd-bugs@freefall.freebsd.org>; Mon, 17 Jun 1996 22:52:40 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id PAA10352; Tue, 18 Jun 1996 15:49:37 +1000
Date: Tue, 18 Jun 1996 15:49:37 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199606180549.PAA10352@godzilla.zeta.org.au>
To: gwk@cray.com, j@uriah.heep.sax.de
Subject: Re: bin/1320: dump limits blocksize to 32K
Cc: freebsd-bugs@freefall.freebsd.org, gpalmer@freebsd.org
Sender: owner-bugs@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>> E. g. how about dumping to a locally attached device with the
>> intention of restoring the tape on another system?  The other system
>> may very well be capable of handling blocksizes > 32.

>Won't work either.  It's not restore(8) that's broken, it's physio(9).
>For both, reading *and* writing.

The same system is actually capable of handling blocksizes up to 64K.
dump(8) is not the place to avoid the brokenness of physio().

Bruce