From: fish@daacdev1.stx.com
Subject: more MTIO questions???
Organization: Goddard Space Flight Center
Date: Mon, 16 Nov 1992 21:50:30 GMT

on a 440S irix 4.0.1 i have the following questions:

1) using the 4mm max block size (Maximum block size: 16777215 bytes
   from mt status) dd returns ENOMEM - Not enough space
   (the tps man page sez this may be that the kernel mem allocator
   couldn't allocate it [the jagtape man page doesnt' have this caveat,
   the ENOSPC comments are quite different too, should they be?] )

   using read(1) from my own code results in the same thing

   i'll have to admit ~16MB is a huge amount (especially for one record)
   but i need to be able to generically be prepared for the largest
   block (variable, see question 4 too) possible...
   (probably using the MTIOCGETBLKINFO call)


2) 4mm when already at EOD 
	a) from my code using regular old read(1) first attempt returns
	   a 0, second read causes "Trace/BPT trap (coredump)"

	b) mt fsr returns ENOSPC (No space left on device)
	c) dd just sez 0+0 records in out w/ no other diagnostics

   why isn't ENOSPC returned from my read? how should i code the check?


3) when reading 4mm from beginning of tape to EOD when last EOF is
   reached EOF is returned (ok)
   
   When read after this is issued EOF is returned again
   (ok, but... it seems to be trying to simulate
   that it reached a double EOF (logical EOT from 9-track world at
   least) when it really isn't - i think i like this but i think that
   8mm tapes on vme/scsi (jag) don't do this (the read after the last
   EOF returns ENOSPC)


4a) is there any speed (or other) advantage to using the fixed block
   device file over the variable?

   i almost always need variable but sometimes if i know its going to
   be 100% fixed size would i see any increase in throughput

   from the manpages/.h files the only advantage i can find of fixed over
   variable is that the record size is limited only to physical memory


4b) when in fixed block mode say its set to 1024 like on 8mm and you
    write 1024*n bytes will the driver lay down IRG's at the 1024 for
    you?  (i know this works ok for read but never tried for write)


5) is there any more info available on the recommended block size field?

   the most i can find is in mtio.h where is sez: '"recommended" block size
   for i/o. Mostly based on compatibility with earlier releases and/or
   other vendors'


6) i'm glad i followed that Usenet thread last month that warned that the 
   jagtape man page TAPE MOVEMENT CRITERIA is incorrect on item #4 where
   it states that the EOFs will be written only if the last write was not
   a WEOF (my code showed the same result and i thought i was going crazy)

   anyway, why is it that 8/4mm don't use the double EOF as logical EOT
   like the 9 tracks?  is it because EOD is so different in helical-scan
   world? could i get a mini-lecture on it.

   related: what is the action on 9 track, 4/8mm w.r.t. MTEOM and
   MTAFILE mtop operations?


7) i see mtget.mt_fileno and mt_blkno seem to be implemented under tpsc
   for 4mm - the mtio.h still states that they are not fully implemented
   i see they are not for kennedy 9-track and jagtape 8mm (are they for
   tpsc 8mm?)  i hope irix 5.0 has this fully supported, does it?


8) ...and if you haven't totally fallen asleep or hit the delete key yet...
   when including mtio.h or jagtape.h i have to include types.h first
   since they use ulong, u_char etc

   is it against ANSI C policy for an include file to include another? (i
   recall something like this)


9) is the only way to use mtget and old_mtget (for librmt, /etc/rmt use)
   to use the rmtops isrmt() function and then pass the correct structure
   to the ioctl()? (the comments in mtio.h are great!)

10) mt man page references mtio.h, it'ld be nice if the FILES section of the
   man page referred to it also (ioctl too), but this is icing on the cake

		thanx,   (to dave hopefully; i'll buy ya a brew next time
			  i'm in mountain view!)
		   fish

p.s. here's to hoping that the new layered drivers will make all the jag/tps
     driver differences totally moot - unfortunately it looks like irix 5.0
     for multi-processors won't be around soon enough to cure (some of) my 
     ills
--
John R. Vanderpool                INTERNET: fish@daacdev1.stx.com
NASA/GSFC                         VOX: 301-513-1683                
Hughes/STX Corporation            FAX: 301-513-1608
"somehow seems strange and a little bit funny, to wander thirsty in the rain" pr
Newsgroups: comp.sys.sgi