|
----- 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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.