Path: utzoo!attcan!uunet!pyrdc!pyrnj!rutgers!cmcl2!phri!roy
From: roy@phri.UUCP (Roy Smith)
Newsgroups: comp.unix.wizards
Subject: Re: Accessing a VAX tape drive from a S
Message-ID: <3463@phri.UUCP>
Date: 7 Sep 88 12:07:42 GMT
References: <711@auvax.UUCP> <43200035@uicsrd.csrd.uiuc.edu>
Reply-To: roy@phri.UUCP (Roy Smith)
Organization: Public Health Research Inst. (NY, NY)
Lines: 36

kai@uicsrd.csrd.uiuc.edu writes:
> > When writing a local tape, each write() call produces one record.
> 
> Not true when a blocking factor > 1 is used.  Each write just adds a little
> to a buffer, and when the buffer is full, THEN one physical record is
> actually produced.

	Say what?  On any Unix system I've ever seen, each write(2) system
call produces exactly one physical tape record.  If you wanted to, you
could do single character writes and get 1 character records (assuming this
didn't put your tape drive/controller into spasms).

	The kernel has no concept of blocking factor.  Programs that use
blocking factors (dump, tar, dd, etc) do the buffering you describe in user
code and present full tape records to the kernel in a single write(2).
From the 4.3 mtio(4) man page (other systems will differ in wording but
should say essentially the same thing):

     "A standard tape consists of a series of 1024 byte records
     terminated by an end-of-file."

	I'm not sure what this is doing in a section 4 man page.  Certainly
the kernel has no concept of what a standard tape looks like, nor does it
prefer to write 1024 byte records over any other size.

     "Each read or write call reads or writes the next record on
     the tape.  In the write case the record has the same length
     as the buffer given."

	The heart of the matter.  You get records on the tape exactly as
long as the byte count you pass to write(2).
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"