Date: Tue, 18 Jun 1996 22:55:14 +0200 (MET DST) From: J Wunsch <j@uriah.heep.sax.de> To: gwk@cray.com Cc: bde@zeta.org.au, freebsd-bugs@freefall.freebsd.org, gpalmer@freebsd.org Subject: Re: bin/1320: dump limits blocksize to 32K Message-ID: <199606182055.WAA09383@uriah.heep.sax.de> In-Reply-To: <199606181304.PAA00455@racer.dkrz.de> from "Georg-W. Koltermann" at "Jun 18, 96 03:04:57 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As Georg-W. Koltermann wrote: > 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 (raw SCSI commands like WRITE BUFFER suffer from it as well). > 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. Your blocksize was an integral multiple of 64 KB, so you might not have noticed the split. (In particular, QIC-150 tapes are always blocked at 512 bytes, so it's irrelevant.) The problems arise only when I) interchanging variable-length blocked tapes with other systems that can handle blocksizes of > 64 KB, like it happened to Jordan's SGI tape, or II) using a blocksize that is not a multiple of 64 KB like 96 KB. All integral multiples of 64 KB are handled like 64. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606182055.WAA09383>