home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / aux / 4017 < prev    next >
Encoding:
Text File  |  1992-11-10  |  4.4 KB  |  81 lines
  1. Newsgroups: comp.unix.aux
  2. Path: sparky!uunet!destroyer!ncar!noao!noao.edu!tody
  3. From: tody@noao.edu (Doug Tody)
  4. Subject: Re: Yet more about 'tc' (blocking issues)
  5. Message-ID: <1992Nov11.032712.26391@noao.edu>
  6. Sender: news@noao.edu
  7. Nntp-Posting-Host: lepus.tuc.noao.edu
  8. Reply-To: tody@noao.edu
  9. Organization: National Optical Astronomy Observatories
  10. References:  <1228@jagubox.gsfc.nasa.gov>
  11. Date: Wed, 11 Nov 1992 03:27:12 GMT
  12. Lines: 67
  13.  
  14. In article <1228@jagubox.gsfc.nasa.gov>, jim@jagubox.gsfc.nasa.gov (Jim Jagielski) writes:
  15. > Is the fact that 'tc' needs to be blocked at 8k a big problem (or pain)
  16. > for most people? So far I've heard from only one person who says that it is,
  17. > but the only reason is because it makes it tough (impossible) to read tapes
  18. > from other workstations that write at 512/1024 and not because of any
  19. > A/UX-world problems.
  20.  
  21. The 8k limitation is a minor nusiance for A/UX-only usage, e.g., file backups,
  22. but is a MAJOR problem if the tape drive is to be used to transfer data to or
  23. from an external, non-A/UX system.
  24.  
  25. For example, at NOAO we have a data analysis package (IRAF) which can run on
  26. A/UX and is used to process astronomical image data.  This data is
  27. voluminous, hundreds of megabytes, and is written to DAT or Exabyte tapes by
  28. the systems used to acquire the data, typically Suns.  On these systems the
  29. standard way to write data transfer tapes is with a variable record size.
  30. For example we might write FITS tapes (an astronomy tape data format) using
  31. a block size of 28800 bytes per tape block.  Given the large amount of data
  32. involved, tape is about the only practical way to transfer this data.  Network
  33. transfer is also feasible, but is not an option for some users, and does not
  34. provide a backup capability.
  35.  
  36. The blocking issue can also be a serious problem for other types of data
  37. interchange, for example tar tapes used to export software.  We cannot
  38. currently write a DAT or Exabyte tar tape on any workstation class machine
  39. at NOAO (Sun, DECstation, VAXstation, IBM RS/6000, MIPS, SGI, HP, ...) which
  40. can be read on an A/UX system, due to the 8k blocking requirement.
  41.  
  42. > I for one don't mind the 8k blocking at all. It makes the driver more
  43. > efficient (and therefore quicker) but you have to recall to block at
  44. > 8k. Of course, if 'tc' used the tape drive's actual physical block size
  45. > as it's blocking factor, then you'd have to block at either 512 or 1024
  46. > or 8192, depending on your tape drive so you'd still have to concern
  47. > yourself about blocking...
  48.  
  49. A variable record size is preferred over a fixed block size since for some
  50. tape formats the record size may have some meaning, and since variable size
  51. records cause fewer transport problems.  If fixed size blocks are used, one
  52. system may use, e.g., 1k blocks and the other 8k blocks, and it may not be
  53. possible to read the tape.  By using variable size records it is possible to
  54. make an exact copy of a 9tk tape on a DAT or Exabyte.
  55.  
  56. There is very little difference in terms of efficiency between fixed blocks
  57. and variable sized records for devices like DAT and Exabyte that use a large
  58. FIFO buffer internally to buffer the data.  So long as this buffer is kept
  59. full during a write the tape will stream, writing data onto tape at the
  60. maximum rate.  For cartridge drives like the DC2000 or QIC with no internal
  61. buffering a large block size is needed to transfer data efficiently, but
  62. this is better done in the application than in the driver.  Rather than
  63. requiring 8k blocks, a good approach would be for the driver for a cartridge
  64. tape device to require that data transfers be a multiple of the physical
  65. device block size, e.g., 512 bytes, and leave it up to the application to
  66. buffer data to cause the tape to stream.
  67.  
  68. Cartridge drives support only fixed size blocks, but DAT and Exabyte are
  69. capable of a variable record size mode as well as a fixed block mode
  70. (variable record size mode is enabled by setting the device block size to 1
  71. byte; in variable record mode each read returns one record).  9 track reel
  72. tape drives support only variable size records.  For DAT and Exabyte a good
  73. driver will provide different device entries for fixed block mode i/o and
  74. variable size record i/o, so that the user can decide which to use.  If the
  75. device is capable of compression, there should be different device entries
  76. for compression mode and non-compression mode as well.
  77.  
  78. -- 
  79. Doug Tody    National Optical Astronomy Observatories
  80. tody@noao.edu   P.O. Box 26732, Tucson, Arizona, 85726
  81.