From: zrlw05@hou.amoco.com (Rusty Wilson)
Newsgroups: comp.unix.questions
Subject: Re: writing to tape larger than 2Gb
Date: 7 Apr 92 12:27:18 GMT
Reply-To: zrlw05@hou.amoco.com
Distribution: usa
Organization: Amoco

In article 193@talgras.UUCP, david@talgras.UUCP (David Hoopes) writes:
>In article <gdqWiln0BwwYF5k5MG@transarc.com> vijay+@transarc.com writes:
>>
>>Hi folks,
>>
>>   I have a question about writing to tape larger than 2Gb.
>>When I keep writing 16k blocks to a tape that has 5Gb capacity,
>>the write system call returns -1 with errno = EINVAL when I
>>finish writing 2Gb. When I put a ioctl(fd,MTIOCTOP, &mtop) with
>>mtop.mt_op = MTWEOF (basically writing a eof marker on tape), one
>>every 1Gb this problem remains. Any one know what the problem is, 
>>and how I do write data blocks to tape beyond the 2Gb and 4Gb limits.
>>Shouldn't the eof marks I put in every 1Gb solve the problem?
>>
>>Thanks,
>>
>>Vijay
>>
>>p.s. its not a limit problem, filesize is unlimited. 
>>        The machine is a sun 4/20 (sunos 4.1.1) running a Exabyte 8500 drive
>
>I would take a wild guess and say that the driver is keeping track of the
>amount of data that has been written to tape.  Some nice programmer didn't
>think about the limits of his variables and used a signed integer.  (2 gig
>is more than anyone would ever use right?)  Simply changing to an Unsigned
>integer would have gotten you to 4 gig.  Keeping a block (512 bytes) 
>instead of a byte count in an unsigned integer, would have streched the 
>limit to 2048 gig.  
>
>2 gig = 2 ^ 31 (2 raised to the 31 power).  More then 2 gig rolls over to
>a negitive number.  Some where along the line they decide that a negitive
>amount is an error.
>
>Apparently they do not clear the amount when you write an EOF mark.  Try
>closing the drive and reopening it every one gig.  This should clear the
>amount.  It is usually kept on a per open basis.
>
>
>-- 
>---------------------------------------------------------------------
>David Hoopes                              Tallgrass Technologies Inc. 
>david@tallgrass.COM                       11100 W 82nd St.          
>Voice: (913) 492-6002 x323                Lenexa, Ks  66214        


The problem is not in the ST driver...  It is upstream from the driver in the
kernel. Sun Consulting did a consulting special for my employer which
relaxes this restriction. The modification was made in a routine called
"vnodeopts" (we got this from Sun Consulting in the form of an object file,
along with some "fixes" to the ST driver.

You can get around the EINVAL problem if you occasionally issue
"lseek(fd,0L,0)" to the open unit. This will reset the "position counter"
and EINVAL will not occur. Further, this will prevent unwanted tapemarks
out in the body of the data stream.

Be warned, depending on the firmware level of your Exabyte 8500, the
drive will behave unpredictably at LEOT (Logical End Of Tape). I will
not go into it here, but the standard Sun ST driver will not cope with
LEOT (under write as well as read operations) properly.

---
----------------------------------------------------------------
Rusty Wilson                         Amoco Production Company
Stf. Geophysicist                    550 Westlake Park BLVD
0708W3 HOU - (713) 556-7082          Box 3092, Houston, TX  77253-3092
Newsgroups: comp.unix.questions