Bill, Mate, you have to update your disk drive knowledge a bit. It's been a long time since a single 56664 track would fit on 3.5 inch disk. If you look at the current crop of 300GB 15K RPM the maximum transfer rate of the disk is 1441Mb/sec.
At 4ms per rotation, that would mean largest track size can be estimated as ((4/1000)*1441)=5.764Mb. That's about 720KB per zone 0 track: nearly a full CKD CYL in a single track. However the sustained data rate is 72-123MB/sec, which is still 30 times faster than a SLED. The speed depends on which zone the data is coming from - inside tracks vs outside tracks. Also consider that pre-fetch in Disk Arrays is in parallel from multiple spindles, to the point where in most cases the backend pre-fetch can stay ahead of a single threaded sequential read. I think it is a long time since backups operated as single track IO. With the prevalence of half track blocks and default five buffers for SAM-E even the much maligned IEBGENER will read 2.5 tracks in a chained SSCH. I usually see DFSMSdss Dumps using OPT(4) which operates at 1CYL per I/O. Just to verify my point, the 377MB/sec for a port was actually 16 ports doing sequential IO from 1024 disk drives for an aggregate 6032MB/sec. We drove this with 64 FX4 channels fanned into 16 Ports. That's 6MB/sec/spindle with 100% sequential cache hit (meaning pre-fetch stayed ahead of Host reads). For the naysayers, these were not little datasets living in cache. These were 2048 datasets of 4001 CYLs each read front to back. That's why I think that 50MB/sec is a good, conservative, working number for most backup products. Ron > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of (IBM Mainframe Discussion List) > Sent: Friday, February 08, 2008 2:53 PM > To: [email protected] > Subject: Re: [IBM-MAIN] VTOC size > > > > In a message dated 2/8/2008 3:45:21 P.M. Central Standard Time, > [EMAIL PROTECTED] writes: > >On FICON it would be reasonable to expect to get 50MB/sec to and from > your > Disk and tape drives. > ... > >So 54,000MB at 50MB/sec is 1080 seconds, or 18 minutes. > > I may be wrong, but I think backup/archive/retrieval/migrate products > that > are operating on a whole volume level do each track serially, so a > backup of a > really huge volume would be limited by the slowest part of the I/O path > which > I believe will be the rotation speed of the disks. No matter how big > the > controller's cache is, sooner or later a backup of an entire really > huge volume > is going to slow down to match the track rotational speed. The SLED > 3390 > rotated at 70 RPS, which at 57K per track yielded about 4MB/second. > RAID > disks rotate a lot faster than the 3390 did, but I think it's on the > order of > twice the RPS rather than 10 to 20 times as fast. I would expect that > a > controller could not cram more than 10MB per second into that 50MB > FICON channel > unless the backup product is doing some kind of multitasking or similar > operation whereby it can do multiple large-scale reads at the same > time. There's no > other way to break the rotation barrier. Do backup products work like > that > yet? 54000 MB at 10MB/second = 5400 seconds = 90 minutes. > > Bill Fairchild > Rocket Software > > > > > > **************Biggest Grammy Award surprises of all time on AOL Music. > (http://music.aol.com/grammys/pictures/never-won-a- > grammy?NCID=aolcmp003000000025 > 48) > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
