Date: Tue, 18 Jun 1996 15:04:57 +0200 (MET DST) From: "Georg-W. Koltermann" <gwk@racer.dkrz.de> To: bde@zeta.org.au Cc: j@uriah.heep.sax.de, freebsd-bugs@freefall.freebsd.org, gpalmer@freebsd.org Subject: Re: bin/1320: dump limits blocksize to 32K Message-ID: <199606181304.PAA00455@racer.dkrz.de> In-Reply-To: <199606180549.PAA10352@godzilla.zeta.org.au> (message from Bruce Evans on Tue, 18 Jun 1996 15:49:37 %2B1000)
next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "Bruce" == Bruce Evans <bde@zeta.org.au> writes:
Bruce>
>>> 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.
Bruce>
>> Won't work either. It's not restore(8) that's broken, it's
>> physio(9). For both, reading *and* writing.
Bruce> The same system is actually capable of handling blocksizes
Bruce> up to 64K. dump(8) is not the place to avoid the
Bruce> brokenness of physio().
Bruce>
Bruce> Bruce
Bruce>
Hmmm, I read about the physio problem earlier, yet I have two problems
with that statement:
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?
b) If physio() is broken for sizes > 64 kB, why was I once able to
pull a cpio archive off my /dev/rwt0, specifying a blocksize of
2 MB? I chose that large block size in order to avoid permanent
start/stop on the tape drive. Worked quite well for me as I
remember.
Just two stupid questions. Feel free to ignore if you think this
thread is getting out of control...
Regards,
Georg-W. Koltermann, gwk@cray.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606181304.PAA00455>