Date: Sat, 28 Dec 1996 16:49:51 +0100 (MET) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-scsi@FreeBSD.org (FreeBSD SCSI list) Cc: ping@red.stepnet.com (Ping Mai) Subject: Re: Q: ideal block size for exb 8505 Message-ID: <199612281549.QAA12728@uriah.heep.sax.de> In-Reply-To: <199612272304.PAA00430@red.stepnet.com> from Ping Mai at "Dec 27, 96 03:04:53 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
As Ping Mai wrote: > I am using dump to backup to a exb 8505xl. can anyone > recommand an ideal block size to get max through > put? i understand that one can also set the block size > using mt. how's this diff from blocksize given to > dump? i am confused. You can only set a fixed blocksize with mt(1). Most drives limit the ability to accept a fixed blocksize to 512 bytes, some also allow for 1024 bytes. Most (and all modern) drives don't work with a fixed block size, but with a variable one (expressed as 0). This basically means they write the amount you pass to the driver in a single write(2) call into a single tape block. Reading these blocks requires a read(2) of at least the same (or a larger) size, and will return exactly the amount of bytes that have been written into that block (i.e., will yield a `short read' when attempting to read more bytes than have been there in the tape block -- that's how restore(8) examines the tape block size). Something like 32 KB is a good value. Larger values reduce the overhead, but the impact is probably getting neglicible above something like 10 KB. Some programs default to 512 bytes only which is stupid and often causes tapes to stop streaming. physio(9) in the kernel currently slices all requests into chunks of 64 KB (this has been discussed at length recently), so you can't really read and write variable-block tapes with more than 64 KB per tape block. dump(8) stupidly even decreases that limit and chokes if you try more than 32 KB. -- 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?199612281549.QAA12728>