Request for feedback - BACKUP enhancement

[Antoniov.]

Hi to all,
Guy Peleg requested for feedback.
Read here:
http://groups.google.com/group/comp.os.vms/browse_thread/thread/610c8021c9d46f38/bc6d9a68ace5587a
http://www.openvms.org/stories.php?story=05/11/07/4758552
Italian speaking people can read here
http://it.openvms.org/itopenvmsforum/viewtopic.php?p=109#109

Please,
submit your mind.

Antonio
http://it.openvms.org

[Uwe Zessin]

I really hope that backup will not loose its robustment like after the first rewrite. My suggestion is that the new functionality is first offered as a separately installable kit (similar to the new LAT stuff in V5.4-3) with the ability to back-out.

[Jan van den Ende]

Guy,

I like the idea of two (more?) simultaneous tapes written.

I have always wondered why the disk-to-memory pass and the memory-to-tape pass had to alternate.
Using half the memory to fill from disk while transfering the other half to tape simultaneous look like a very simple way for significant speedup.
And the idea is hardly new: in the early 80's I wrote somthing along those lines as a print despooler (for Qume printers having 2 128-byte buffers).

Like some of the others on COV I am not yet convinced that striping will be advantageous for restorability.

I do not know if this is even possible, but would it (PLEASE!!) be possible to re-introduce BACKUP's ability for recovering tape errors (also on SCSI tapes).
I could live with write errors remaining uncorrectable, but loosing a full tape of backup because of ONE parity error still looks REAL stupid!

Guy, GO FOR IT.
If anyone can do it, you are that one.

Proost.

Have one on me.

jpe

[David Jones_21]

>>Like some of the others on COV I am not yet convinced that striping will be advantageous for restorability.<<

It's disadvantageous from the increased risk of tape failure, but advantageous from the perspective that full image restore would happen up to n times faster (for a stripe set with n tape drives).

Geez people, the proposal was for the tape equivalent of RAID 0 and RAID 1 and everyone's demanding it be RAID 5.

The last time I worked on a system with dual tape drives, Reagan was president.

[Galen Tackett]

Jan,


I do not know if this is even possible, but would it (PLEASE!!) be possible to re-introduce BACKUP's ability for recovering tape errors (also on SCSI tapes).
I could live with write errors remaining uncorrectable, but loosing a full tape of backup because of ONE parity error still looks REAL stupid!


I think this has been discussed before at some length probably both here and on c.o.v. Though I don't know the details I believe this inability to recover from tape errors isn't backup's fault, but is due to the way that newer tape subsystems work.

Others here can probably better summarize why this is true.

Maybe VMS's tape parity error message is too generic? If memory servers this kind of error might bue due to much more serious problems than just a bad bit or two, perhaps even so serious that the tape is literally unreadable beyond that point.

[Ian Miller.]

The issue with modern tapes is due to what the tape firmware does in reaction to an error.

BACKUP could be improved to give better error reports if it gets enough enough information back from the tape drive.

[Jan van den Ende]

Ian,

I _know_ it is a SCSI firmware issue.
I am just praying that there is some way to force it to resume, _AND_, in that case, I dearly wish Engeneering to implement that ïn a way that makes BACKUP resume its old behavior.

There must be _SOME_ way around the parity error, as demonstrated by the info rescue companies.
But I have not the faintest idea whether some of their methods can be integrated into BACKUP :-(
Just hoping, and keep pushing.

After all, Ã got much the same answer when asking for SCSI minimerge. And I asked again and again at every Decus Engeneering panel, year after tear. It took over 10 years, but: LOH & BEHOLD !

Proost.

Have one on me.

jpe

[Wim Van den Wyngaert]

Bigger blocksizes on tape would be nice to get better performance. May be time to modify RMS ...

And /stat to get statistics of thruput and save set size.

And writing directly to remote tapes using TCP and DECNET.

And /group should default at 0.

And dismount/wait=rewind should wait until the tape is rewinded.

Wim

[Ian Miller.]

Wim - I would not be surprised if some of your wishes appear in a future version of vms

jpe - DEC used to do their own firmware for other peoples tapes. I don't know if hp do but if they did then they could fix this.

[Cass Witkowski]

I remember many years ago some took 5 TKxx or DLT tape drives and with hardware created a RAIT-3 tape backup. The system thought it was one tape drive but it wrote data out to 5 tapes. One being parity so if you lost a tape you would not lose all your data. I think the throughput was 12 MB/second which was pretty good at the time.

I'm currently testing out Ultrium LTO 2 tape drives as replacements to TZ89s. The problem I have is how much CPU time backups take.

On a DS10 (4/466) system I can back up to a TZ89 at 8.37 MB/s using 38% of the CPU. This is with the default of /CRC and /GROUP=10.

Using the new Ultrium LTO 2 tape drive I can backup at 21 MB/s but I'm using 100% of the CPU

If I set /GROUP=0 I still use 100% of the CPU but I can backup at 25.63 MB/s

If I set /NOCRC my CPU utilization drops to 33% but I only backup at 23.14 MB/s due to those group XOR blocks

If I set /NOCRC and /GROUP=0 the CPU utilization drops to 15% and my backup rate is 25.63 MB/s

The point I'm trying to make is that to really get the throughput without killing the system then we need to re look at the effectiveness of the /CRC qualifier. With the current generation of SCSI and Fibre Channel interfaces and the error detection on tape drives what is the value of using /CRC?

What is the probability of a undetected error getting through the system? This is the only thing that /CRC is good for. It's not the error rate of the tape drive it is the undetected error rate of the tape drive and the interface (SCSI or FC) from the host to the tape drive. Is CRC buying us anything.

It has a big impact on how fast I can backup my data and not kill my CPU.

I like the ability to shadow tapes but also mention earlier to be able to make a copy of a tape especially if the block size is larger than 32,256.

I think if you are going to stripe tapes you may want to look at also providing a RAIT-3 capability which give us some sense of recovery if we lose a tape. This would be a nice feature for those who have to archive data.

If you can add statistics or performance metrics in backup such that we can track where backup is waiting. This will help simplify tuning of backups.

Thanks

Cass