Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: dan@breeze.bellcore.com (Daniel Strick)
Newsgroups: comp.sys.sun
Subject: Re: Myths about tape block sizes
Keywords: Hardware
Message-ID: <986@brchh104.bnr.ca>
Date: 31 Dec 90 17:28:40 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 30
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n405
X-Sun-Spots-Digest: Volume 9, Issue 414, message 7
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

The SCSI transfer count limit for a single sequential access read/write
command is 2^24.  If the tape is QIC, the units are 512 byte records.  You
won't hit this limit.

The magic number 126 was probably chosen because the traditional mag tape
minphys() limit is 63 kb.  (Raw device drivers gratuitously split up large
i/o requests into chunks of the minphys() size.  The usual motivation is a
limited i/o dma memory map.  See the documentation for physio() in the
manual on writing device drivers.)

The 63 kb limit for mag tape is actually arbitrary (and arguably stupid
because then you can't read 9 track tapes with 64 kb records and such
tapes do exist).  SunOS installation manuals have more recently
recommended the use of 100 kb buffer sizes with SCSI cartridge tape,
suggesting that the minphys limit was changed in the st driver (can't tell
without looking at the source).  Possibly someone did a few performance
tests and discovered that the particular system on his/her desk ran those
particular performance tests faster at that buffer size.

It is also possible that someone arbitrarily decreed that bigger was
better on average.  There is some justification for this attitude (since
otherwise you have to repeat performance tests for each possible system
configuration), but bigger doesn't always win.  For example, modern SCSI
tape and disk systems have lots of internal data buffers and can overlap
i/o operations.  They may stream quite well when you use small buffer
sizes.  A large buffer size may prevent continuous streaming.  It depends
on the specific system and pattern of i/o activity.  There is no
universally optimum buffer size.

Dan Strick, aka dan@bellcore.com or bellcore!dan, (201)829-4624