home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / unix / admin / 4320 < prev    next >
Encoding:
Internet Message Format  |  1992-07-25  |  3.2 KB
  1. Path: sparky!uunet!olivea!sgigate!odin!fido!zola!zuni!anchor!olson
  2. From: olson@anchor.esd.sgi.com (Dave Olson)
  3. Newsgroups: comp.unix.admin
  4. Subject: Re: multiple dumps on EXB-8200 8mm tape
  5. Message-ID: <noca1fk@zuni.esd.sgi.com>
  6. Date: 25 Jul 92 18:22:58 GMT
  7. References: <1992Jul23.141833.14606@ferrari.nmc.ed.ray.com> <1992Jul24.181553.10455@kakwa.ucs.ualberta.ca>
  8. Sender: news@zuni.esd.sgi.com (Net News)
  9. Distribution: usa
  10. Organization: Silicon Graphics, Inc.  Mountain View, CA
  11. Lines: 56
  12.  
  13. In <1992Jul24.181553.10455@kakwa.ucs.ualberta.ca> sherwood@fenris.space.ualberta.ca (Sherwood Botsford) writes:
  14.  
  15. | Bill Heiser writes
  16. | > The problem I have is that when I write a tapefile to the non-rewinding
  17. | > device, and then write another file, when I try to read the files I seem
  18. | > to have to skip filemarks sometimes.  For example:  If I write a tape on
  19. | > a SunOS 4.1.1_U1 or 4.0.3 system, I have a tape with several tapefiles.
  20. | > If I try to read the tape by doing several consecutive 'restore' commands
  21. | > on the non-rewinding device, the restores after the first one fail -- unless
  22. | > I do a restore, then a "mt -f fsf 1".  So basically I seem to be getting
  23. | > extra file marks!
  24. | 
  25. | This one threw me for a loop initially.
  26. | The file mark is not (usually) explicitly written by the program, but is  
  27. | written by the computer on closing the file.  It will aslo be done by the tape  
  28. | if the previous command was write data, and the the current command is any tape  
  29. | movement command.
  30.  
  31. This is incorrect.  The drive itself will *never* write a filemark.  It
  32. will write an EOD mark if you are writing, then rewind, space backwards,
  33. etc.
  34.  
  35. | Now, a filemark on either exabyte or DAT drives has a front and back side.   
  36. | Front being on the Beginning of Tape side.  
  37. | 
  38. | Any command that writes to the tape, finishes with a write filemark, and   
  39. | leaves the head on the back side of the mark, ready to write the next file.
  40. | 
  41. | Any command that reads the tape leaves the tape positioned on the BOT side of  
  42. | the file mark.
  43.  
  44. Wrong.  A read that actually encounters the FM (e.g., a read when
  45. positioned at the BOT side of a FM) will return no data (or short
  46. count, if you had some data before you hit the FM), and the tape
  47. will be positioned on the EOT side of the FM.  Exabyte has a nice
  48. series of diagrams in their appendix covering just about every
  49. possible case for FM's, EOD, etc. that explain this quite well.
  50.  
  51. | mt fsf's and bsf's behave this way too.  A bsf leaves the tape on the front  
  52. | edge of the filemakr, and an fsf leaves it on the back.
  53. | 
  54. | So if you kill an operation, and want to reposition the tape to start it again,  
  55. | you must do this:
  56. | mt bsf 1
  57. | mt fsf 1
  58.  
  59. This is wrong.  If you want to record on an Exabyte 8200, you
  60. must be in one of 3 places: BOT, BOT side of a FM, or EOD.  If I
  61. remember correctly, the 8500 will also allow you to record at the EOD
  62. side of a FM.  So you do not want to do the mt fsf 1 after the bsf
  63. if you want to overwrite some data on the tape for 8200's
  64.  
  65. --
  66. Let no one tell me that silence gives consent,  |   Dave Olson
  67. because whoever is silent dissents.             |   Silicon Graphics, Inc.
  68.     Maria Isabel Barreno                        |   olson@sgi.com
  69.