home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / sgi / 16512 < prev    next >
Encoding:
Text File  |  1992-11-17  |  4.7 KB  |  118 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!ukma!nsisrv!news2.gsfc.nasa.gov!fish
  3. From: fish@daacdev1.stx.com
  4. Subject: more MTIO questions???
  5. Message-ID: <fish.721950630@news2.gsfc.nasa.gov>
  6. Sender: usenet@nsisrv.gsfc.nasa.gov (Usenet)
  7. Nntp-Posting-Host: daacdev1.stx.com
  8. Organization: Goddard Space Flight Center
  9. Date: Mon, 16 Nov 1992 21:50:30 GMT
  10. Lines: 106
  11.  
  12. on a 440S irix 4.0.1 i have the following questions:
  13.  
  14. 1) using the 4mm max block size (Maximum block size: 16777215 bytes
  15.    from mt status) dd returns ENOMEM - Not enough space
  16.    (the tps man page sez this may be that the kernel mem allocator
  17.    couldn't allocate it [the jagtape man page doesnt' have this caveat,
  18.    the ENOSPC comments are quite different too, should they be?] )
  19.  
  20.    using read(1) from my own code results in the same thing
  21.  
  22.    i'll have to admit ~16MB is a huge amount (especially for one record)
  23.    but i need to be able to generically be prepared for the largest
  24.    block (variable, see question 4 too) possible...
  25.    (probably using the MTIOCGETBLKINFO call)
  26.  
  27.  
  28. 2) 4mm when already at EOD 
  29.     a) from my code using regular old read(1) first attempt returns
  30.        a 0, second read causes "Trace/BPT trap (coredump)"
  31.  
  32.     b) mt fsr returns ENOSPC (No space left on device)
  33.     c) dd just sez 0+0 records in out w/ no other diagnostics
  34.  
  35.    why isn't ENOSPC returned from my read? how should i code the check?
  36.  
  37.  
  38. 3) when reading 4mm from beginning of tape to EOD when last EOF is
  39.    reached EOF is returned (ok)
  40.    
  41.    When read after this is issued EOF is returned again
  42.    (ok, but... it seems to be trying to simulate
  43.    that it reached a double EOF (logical EOT from 9-track world at
  44.    least) when it really isn't - i think i like this but i think that
  45.    8mm tapes on vme/scsi (jag) don't do this (the read after the last
  46.    EOF returns ENOSPC)
  47.  
  48.  
  49. 4a) is there any speed (or other) advantage to using the fixed block
  50.    device file over the variable?
  51.  
  52.    i almost always need variable but sometimes if i know its going to
  53.    be 100% fixed size would i see any increase in throughput
  54.  
  55.    from the manpages/.h files the only advantage i can find of fixed over
  56.    variable is that the record size is limited only to physical memory
  57.  
  58.  
  59. 4b) when in fixed block mode say its set to 1024 like on 8mm and you
  60.     write 1024*n bytes will the driver lay down IRG's at the 1024 for
  61.     you?  (i know this works ok for read but never tried for write)
  62.  
  63.  
  64. 5) is there any more info available on the recommended block size field?
  65.  
  66.    the most i can find is in mtio.h where is sez: '"recommended" block size
  67.    for i/o. Mostly based on compatibility with earlier releases and/or
  68.    other vendors'
  69.  
  70.  
  71. 6) i'm glad i followed that Usenet thread last month that warned that the 
  72.    jagtape man page TAPE MOVEMENT CRITERIA is incorrect on item #4 where
  73.    it states that the EOFs will be written only if the last write was not
  74.    a WEOF (my code showed the same result and i thought i was going crazy)
  75.  
  76.    anyway, why is it that 8/4mm don't use the double EOF as logical EOT
  77.    like the 9 tracks?  is it because EOD is so different in helical-scan
  78.    world? could i get a mini-lecture on it.
  79.  
  80.    related: what is the action on 9 track, 4/8mm w.r.t. MTEOM and
  81.    MTAFILE mtop operations?
  82.  
  83.  
  84. 7) i see mtget.mt_fileno and mt_blkno seem to be implemented under tpsc
  85.    for 4mm - the mtio.h still states that they are not fully implemented
  86.    i see they are not for kennedy 9-track and jagtape 8mm (are they for
  87.    tpsc 8mm?)  i hope irix 5.0 has this fully supported, does it?
  88.  
  89.  
  90. 8) ...and if you haven't totally fallen asleep or hit the delete key yet...
  91.    when including mtio.h or jagtape.h i have to include types.h first
  92.    since they use ulong, u_char etc
  93.  
  94.    is it against ANSI C policy for an include file to include another? (i
  95.    recall something like this)
  96.  
  97.  
  98. 9) is the only way to use mtget and old_mtget (for librmt, /etc/rmt use)
  99.    to use the rmtops isrmt() function and then pass the correct structure
  100.    to the ioctl()? (the comments in mtio.h are great!)
  101.  
  102. 10) mt man page references mtio.h, it'ld be nice if the FILES section of the
  103.    man page referred to it also (ioctl too), but this is icing on the cake
  104.  
  105.         thanx,   (to dave hopefully; i'll buy ya a brew next time
  106.               i'm in mountain view!)
  107.            fish
  108.  
  109. p.s. here's to hoping that the new layered drivers will make all the jag/tps
  110.      driver differences totally moot - unfortunately it looks like irix 5.0
  111.      for multi-processors won't be around soon enough to cure (some of) my 
  112.      ills
  113. --
  114. John R. Vanderpool                INTERNET: fish@daacdev1.stx.com
  115. NASA/GSFC                         VOX: 301-513-1683                
  116. Hughes/STX Corporation            FAX: 301-513-1608
  117. "somehow seems strange and a little bit funny, to wander thirsty in the rain" pr
  118.