This thread triggered some thoughts and questions in my head. I'd be interested in comments on what others do.
I think the question is less tied to "RAID" as more to the fact that modern disk subsystems use off the shelf harddisks used in the (non-System z) server world as well as in PCs and the like. (There sure are different quality and reliability levels, though). These disk subsystems have to emulate System z CKD DASD devices on those fixed block disks. So, Kees' statement holds true even if no RAID was involved. (Granted, there probably are no non-RAID disk subsystems out there you can connect to System z.) IMHO, there were two reasons that led to the "half track blocking" rule: 1. Reduce physical I/Os. Back when the track size was below 32k, you wanted "full track blocking", because one track would fit into the maximum sized I/O buffer (32k). 2. Use that very expensive physical space as much as possible. Full track was again the way to go until track sizes became larger than 32k. Full track blocking was no longer feasible because of the buffer size limitation. Going half track blocking let you use as much space as possible while minimizing I/O operations needed to read one track of data. Nowadays, storage is realively cheap, but I/O is still expensive (when talking about perfomance). This raises the question if using 32k blocking would not be better than half track blocking with modern disk subsystems? Logically seen (or from a z/OS perspective), there would be a waste of ~24k per track. However, those modern disk subsystems use fixed size blocks of 512 bytes (or are they using larger blocks today?). I expect (but don't really know) that unused track space is not mapped to physical storage blocks, so there would be no waste of physical space. OTOH, todays System z 3390 DASD is limited in the number of cylinders (and thus tracks). So, logical space would indeed still be vasted. And this might be a limiting factor because the number of 3390s is limited. Finally, this might still vote for half track blocking rule. Any thoughts -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
