Re: Reducing downtime for backups

["Brad Jensen" <brad@xxxxxxxxxxx>]

----- Original Message -----
From: "Chris Bipes" <chris.bipes@cross-check.com>
To: <midrange-l@midrange.com>
Sent: Friday, November 30, 2001 6:37 PM
Subject: RE: Reducing downtime for backups


> But as you increase disk arms, i.e. drives, you get higher
through put.  As
> your through put goes up, your IOP, CPU and Main ASP Disk load
will go up.
> Now if those do NOT become a bottle neck, you will still see
90+% disk
> utilization on your secondary ASP BUT your run time will go
down.
>
> Any body want to back me up on this?

Can you isolate the secondary ASP to a set of drives so the head
motion doesn't conflict? I assume this is what you mean.  Can you
control block size on the SAVF (you want it as large as possible)
to reduce head motion?
>
> And I do not take any offense to you or anyone on this list
questioning what
> I post.

Well there goes all my fun. I once read a descriptio of the
debugging cycle, and it begins with '1. User reporta a bug to IT.
2."How dare they slander my software?..."

More notes below, as comments on the statements of the previous
unflappable correspondent.

> Christopher K. Bipes   mailto:ChrisB@Cross-Check.com
> Operations & Network Mgr  mailto:Chris_Bipes@Yahoo.com
> CrossCheck, Inc.   http://www.cross-check.com
> 6119 State Farm Drive   Phone: 707 586-0551 x 1102
> Rohnert Park CA  94928   Fax: 707 586-1884
>
> -----Original Message-----
> From: prumschlag@phdinc.com [mailto:prumschlag@phdinc.com]
> Sent: Friday, November 30, 2001 1:22 PM
> To: midrange-l@midrange.com
> Subject: RE: Reducing downtime for backups
>
> Chris,
>
> Don't take this wrong, but I have trouble swallowing that.  I
have to go
> back to
> basics on this and in my (admittedly simplistic) view it goes
like this:
> CPU -
> Fast;   Disk - Not So Fast,   Tape - Really Slow.

Not so. Disk - fast random access, decent serial access. Tape:
rotten random access, great to excellent serial access. A user
told us about her new tape drive 15 to 30 MB a second transfer
depending on compression. Look at her actualy 40GB daily backup,
and she is getting about 5 MB a second actual throughput. That's
tape repositioning and CPU and disk lag.

> For this job, the CPU has
> nothing else to do, so it will always be waiting on the disks,
so no matter
> how
> many I throw at it the disk busy percentage will always be high.
If my
> lousy
> memory serves me correctly, IBM invented *SAVF files for the
express purpose
> of
> reducing downtime for backups.  Has tape processing improved so
much that
> one
> tape drive can record data faster than 6 read/write heads on
disk?

Tape transfer times continue to improve, partly because they are
getting so much more density on the tapes. However, because of
this positioning times take up a greater and greater percentage of
the tape write time.

On your average disk drive, head positioning including settling
and rotational delay takes up (I am guessing) better than 95% of
your transfer time. Disks now have higher density than tapes per
cc, which they can do because the environment is non-contact and
much better controlled. I think tapes are still pretty much
contact devices, aren't they?

(I could be entirely full of beans on this, but I think my basic
observation is right. If there is some real tape head physicist
lurking, please rescue me.)

Diska make up for this with caching of various types - read more
than you need, since they extra read time is trivial percentage
wise, and you then have the disk in RAM memory - a hudnred
thousand times faster than disk. If you do write behind caching,
and you have enough memory, it's even better - your disk write
goes to memory, then as memory continues to fill you look for the
closest tracks that need writing and write them first, minimizing
the randomness of disk seeking.

With RAM prices  going so low, don't be surprised to see IBM come
out with disk drives that have 10, 20, 30 GB of cache and
performance improvements that are out of this world. That's what I
would be doing now. Read a system file from disk once, then update
and read it again from RAM all day, and maybe you don't get around
to writing it until third shift. Better build your primary UPS
right into the drive.


>  Or is it
> possible that the RAID processing on these disks is causing so
much
> thrashing
> that the whole system is bouncing up and down in the computer
room?
>
> Phil

Sorry, out of milk.

Brad Jensen