| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 2114.1 | It depends | ELWOOD::KAPLAN | Larry Kaplan, DTN: 237-6872 | Wed Mar 09 1994 18:30 | 18 |
| 2114.2 | SUN to be specific... | BAHTAT::RUSHWORTH | Why is there only 1 Monopolies Commission? | Thu Mar 10 1994 15:34 | 7 |
| 2114.3 | | ELWOOD::KAPLAN | Larry Kaplan, DTN: 237-6872 | Thu Mar 10 1994 17:59 | 3 |
| 2114.4 | Customer Question | ODIXIE::KEMP | | Wed Mar 16 1994 17:42 | 13 |
| 2114.5 | | ELWOOD::PETERS | | Wed Mar 16 1994 20:20 | 11 |
| 2114.6 | Thanks | ODIXIE::KEMP | | Wed Mar 16 1994 21:55 | 7 |
| 2114.7 | More questions... | MILBRN::RUSHWORTH | Why is there only 1 Monopolies Commission? | Mon Mar 21 1994 00:05 | 21 |
| 2114.8 | | ELWOOD::PETERS | | Mon Mar 21 1994 16:01 | 17 |
| 2114.9 | | SSDEVO::FROEHLIN | Between my ears? 80% water or what? | Mon Mar 21 1994 18:46 | 13 |
| 2114.10 | How long for a full restoration | OTOOA::LAVIGNE | | Tue May 10 1994 23:21 | 11 |
| 2114.11 | | DECWET::GETSINGER | Prod Mgr - POLYCNTR HSM for UNIX | Thu Jun 09 1994 08:33 | 17 |
| 2114.12 | OSF I/O guru needed | ELWOOD::KAPLAN | Larry Kaplan, DTN: 237-6872 | Thu Jun 09 1994 17:31 | 15 |
| 2114.13 | | DECWET::GETSINGER | Prod Mgr - POLYCNTR HSM for UNIX | Fri Jun 10 1994 18:34 | 2 |
| 2114.14 | at long last... | CUJO::SAMPSON | | Thu Jan 09 1997 05:58 | 19 |
| 2114.15 | | TAPE::PETERS | | Thu Jan 09 1997 21:31 | 9 |
| 2114.16 | Faster skipfile is in V7.1 | STAR::S_SOMMER | | Fri Jan 10 1997 16:33 | 17 |
| 2114.17 | Be sure MKSET is used locally on 7.1 tape dens set | EVMS::EVERHART | | Wed Jan 29 1997 15:28 | 9 |
| One thing to note about the new MK skipfiles stuff. If using MKSET to
alter tape behavior defaults, remember it must be run on the same
machine where the tape is on a local SCSI bus; mkset does not work
across servers. (Rotorooting the TMSCP spec was not feasible.)
Thus if say "MKA300:" doesn't work but you'd use "$3$MKA300:", the
device is probably not local...
glenn
|
| 2114.18 | Customer has compromised the new algorithm? | CSC32::D_BROWN | Dave Brown CSC-VSG/INTDRV | Mon Jun 02 1997 22:20 | 21 |
|
Could the new algorithm at all be responsible for a dramatic *increase*
in backup time to a TZ87 (TZ887)? I'm working with a customer who since
upgrading to V7.1 Alpha has noticed backups sometimes take up to 10
hours longer than they used to. His procedure is quite poor but used to
not take so long and I'm wondering if performing backups in such a
manner will kill the efficiency of the new algorithm. Here's what he
does for each disk volume; one batch job per backup:
1) Mount tape
2) Backup disk
3) Dismount tape
4) Next batch job starts with step 1
This is repeated until all his disks have been backed up.
Thanks,
Dave
|
| 2114.19 | | COOKIE::FROEHLIN | VMS...riding into the setting sun! | Tue Jun 03 1997 21:23 | 17 |
| .18>upgrading to V7.1 Alpha has noticed backups sometimes take up to 10
Sometimes? Exactly when? Could it be that sometimes it needs a
continutaion tape and there's no one around for 10 hours to mount a new
one?
.18> 1) Mount tape
.18> 2) Backup disk
.18> 3) Dismount tape
.18> 4) Next batch job starts with step 1
BACKUP will do a "SKIP TMs 32000" to reach the logical-end-of-tape to
append another save set. I would expect the new behavior in MKDRIVER
to improve the skip time. What kind of SCSI controller is this tape
connected to?
Guenther
|