Dan Karron@UCBVAX.BERKELEY.EDU (12/22/90)
Dave Olson write about what Peter S. Shenkin writes: >I'm not clear on what you mean by 'recognize' here. By default, bru >uses the 'normal' method of doing multivolume tapes on IRIX (for the >SCSI and and xm tape drives), which is to write until EOT is detected, >then switch to a new volume. To do this, the tape sizes are set to 0K >in /etc/brutab. There is absolutely no way to determine tape lengths ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^HUH??? >ahead of time, since e.g. a QIC 150 drive could have either QIC150 or >QIC120 cartridges, in any of several lengths. This is true of most >types of tape drives. If you are certain of the capacity, and are sure >you will use exactly the same tape type and length for each volume, you >could use the -s option to specify the length, or edit /etc/brutab. > >| It is also a real pain that -e does not work with -Z; the FM does not >| mention this limitation; however, an attempt to do this elicits an error >| message. I submit that just about the only time you need -e is when you use >| -Z; yet that's when you can't get it. > >The reason it doesn't do this is that it would actually have to read and >compress every single file in order to determine how much space the >compressed files would require. This is incredibly slow. If you really ^^^^^^^^^^^^^^^SO WHAT! >wanted to know, you could always do something gross like: > bru -cvfZ /dev/null .... | tail > Sounds like a good idea, actually. Since my tape backup is done automatically from crontab in the dead of night after I leave, I don't really care how slow it is. I mt ret the tape a number of time during the backup process just for its good health. My main worry is the tape filling up and the Night Backup script not knowing what to do. I compress the data to put off the eventual EOT . I would like some foolproof way to know in advance if I am goint to hit EOT, not blunder on it and risk corrupting my backup. That way I can do something intelligent before it happens! We need a program to size any serial media (qic,dat, etc). I have seen it on more business oriented computer systems (NCR unix). We also need a taylored bru tab that know about sgi boxes (there are no entries for sgi tape devices in the bru tab!) Cheers! dan. +-----------------------------------------------------------------------------+ | karron@nyu.edu (E-mail alias that will always find me) | | Fax: 212 340 7190 * Dan Karron, Research Associate | | . . . . . . . . . . . . . . * New York University Medical Center | | 560 First Avenue \*\ Pager <1> (212) 397 9330 | | New York, New York 10016 \**\ <2> 10896 <3> <your-number-here> | | (212) 340 5210 \***\_________________________________________ | | Main machine: karron.med.nyu.edu (128.122.135.3) IRIS 85GT | +-----------------------------------------------------------------------------+
olson@anchor.esd.sgi.com (Dave Olson) (12/23/90)
In <9012220452.AA17500@karron.med.nyu.edu> Dan Karron@UCBVAX.BERKELEY.EDU writes: | Dave Olson write about what Peter S. Shenkin writes: | >in /etc/brutab. There is absolutely no way to determine tape lengths | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^HUH??? | >ahead of time, since e.g. a QIC 150 drive could have either QIC150 or | >QIC120 cartridges, in any of several lengths. This is true of most | >types of tape drives. I guess this wasn't clear enough. What I meant is that there is no way (in general) to tell what size tape is in a drive. For some tape drives, such as the Archive 2150S, one can tell whether a QIC120 or QIC150 cartridge is present (~ 120 vs 150 Mb), but not if there is a 250 Mb cartridge. Similarly for 9 track (5 different common lengths), and 8mm (4 common different lengths). Certainly a PROGRAM could tell ahead of time (at least for the first volume), but there is rarely a reason to do so, since the program can get a reliable end of tape indication when actual EOT is reached, and then continue on the next tape (with the exception of the ts driver due to firmware bugs). See below also. ... | Sounds like a good idea, actually. Since my tape backup is done automatically | from crontab in the dead of night after I leave, I don't really care how | slow it is. I mt ret the tape a number of time during the backup process | just for its good health. My main worry is the tape filling up and the | Night Backup script not knowing what to do. I compress the data to put off | the eventual EOT . I would like some foolproof | way to know in advance if I am goint to hit EOT, not blunder on it and | risk corrupting my backup. That way I can do something intelligent before | it happens! I'm not that it matters too much. Since the cron script can only use the one tape cartridge, the best you can do is to backup one tapes worth. bru (or tar, or cpio) will then ask for the next tape. Since there is no controlling tty, the prompt will fail and the backup aborts. You still have the first tapes worth of backup. If you have multiple drives it would be useful to have a way to specify to bru that it should switch to a subsequent drive without reading from /dev/tty, but that is about all one could do. It might be nice if bru would checkpoint so that the rest of the backup could be continued later, but one runs into potential problems of the filesystem structure changing in between the two runs. Certainly hitting EOT during the backup isn't going to corrupt your backup. It sounds as though you are doing multiple bru's with the norewind device. As long as you are doing an mt feom in between each (or not repositioning the tape at all between backups), there should be no problem; attempts to write after hitting EOT will simply fail. (NOTE: as previously posted in this group, there was a bug that hit 8mm drives that occasionally caused them to position incorrectly with multiple tape files in 3.2; this was fixed in 3.3; however this bug had nothing to do with hitting EOT.)) | We need a program to size any serial media (qic,dat, etc). I have seen it | on more business oriented computer systems (NCR unix). We also need | a taylored bru tab that know about sgi boxes (there are no entries for | sgi tape devices in the bru tab!) Sizing any ONE tape before starting a backup is easy programmatically, sizing all of the volumes of a multi-volume backup in the order they will be used is unreliable due to the human element; the same problem exists with a jukebox, but at least the order of the tapes is unlikely to change in that case. The SGI tape devices ARE in the brutab, see my earlier postings. -- Dave Olson Life would be so much easier if we could just look at the source code.
fnf@riscokid.UUCP (Fred Fish) (01/10/91)
In article <1990Dec22.204946.28873@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: >I'm not that it matters too much. Since the cron script can only use the >one tape cartridge, the best you can do is to backup one tapes worth. >bru (or tar, or cpio) will then ask for the next tape. Since there >is no controlling tty, the prompt will fail and the backup aborts. >You still have the first tapes worth of backup. You can use the brutalk program to communicate with background versions of bru that have no controlling terminal. This is a short program which EST provides in source form to all customers (not sure if SGI passes it on). Bru is told to direct all queries, and receive replies, from a pair of fifos. Brutalk hangs out at the other end and communicates with the user when required. >If you have multiple >drives it would be useful to have a way to specify to bru that it >should switch to a subsequent drive without reading from /dev/tty, This is called device chaining. You simply use multiple -f options. I.E. bru -f /dev/rmt/tp0 -f /dev/rmt/tp1 -f /dev/rmt/tp2 and bru automatically switches to the next drive when required. -Fred
olson@anchor.esd.sgi.com (Dave Olson) (01/11/91)
In <14372@mcdphx.phx.mcd.mot.com> fnf@riscokid.UUCP (Fred Fish) writes: | In article <1990Dec22.204946.28873@odin.corp.sgi.com> olson@anchor.esd.sgi.com (Dave Olson) writes: | >I'm not that it matters too much. Since the cron script can only use the | >one tape cartridge, the best you can do is to backup one tapes worth. | >bru (or tar, or cpio) will then ask for the next tape. Since there | >is no controlling tty, the prompt will fail and the backup aborts. | >You still have the first tapes worth of backup. | | You can use the brutalk program to communicate with background versions | of bru that have no controlling terminal. This is a short program | which EST provides in source form to all customers (not sure if SGI | passes it on). Bru is told to direct all queries, and receive replies, | from a pair of fifos. Brutalk hangs out at the other end and communicates | with the user when required. We don't ship it because we don't have it. Perhaps it was added after the version we licensed (no doubt with the hooks to make it work). We have made so many changes and 'enhancements' to bru that re-integrating with the current version from EST would be a significant amount of work. I don't think that is likely to be done in the near future; there are better programs to spend time and energy on. bru is also very wasteful of tape, so it is not used by all that many people (at least very few of the people at SGI, and judging by relative volume of questions/problems related to tape and backup programs, by our customers either). It also tends to take longer to complete backups, sometimes MUCH longer, then tar, cpio, or dump/restore It is used by our system manager tool for backups and restores, so it will definitely continue to be supported and bug-fixes made, but no plans exist to update to newer versions (I hadn't even heard of newer versions until your posting). The integration of bru with the system manager tool makes integrating new features from EST even more difficult, of course. | >If you have multiple | >drives it would be useful to have a way to specify to bru that it | >should switch to a subsequent drive without reading from /dev/tty, | | This is called device chaining. You simply use multiple -f options. | I.E. | | bru -f /dev/rmt/tp0 -f /dev/rmt/tp1 -f /dev/rmt/tp2 | | and bru automatically switches to the next drive when required. Yes, this would be a nice feature, but unfortunately, it doesn't work (at least in the version that SGI has). The final -f option is the only one that is used. -- Dave Olson Life would be so much easier if we could just look at the source code.