It was not an article of faith; it was a proven reality with that disk fragmentation could significantly rob MPE/V systems of performance. And we had at least two HP provided means for managing disk space. We could use VINIT's CONDENSE command to crudely defragment a drive creating contiguous areas of free space. [Trivia question 1: Originally the granularity was user definable, but was eventually hard coded to what number of sectors?] We could also could define, or at least tune, the algorithm MPE used to determine where it would place file extents. [Trivia question 2: How did you do this?]
When MPE/XL came out we were told that fragmentation had little consequence on system performance. We were pretty much asked to accept this as an article of faith, since there was little if any data to back up the assertion. Gone was CONDENSE. Gone was the ability to tune the disk-allocation algorithm. We were not happy.
It might have all ended there with a few grumbling old-timers but for two things. First, there is the matter of contiguous free space for operating system updates. Even as far back as 1977, MPE, whether MPE II or MPE/iX 5.5, has always required a block of contiguous free disk space on LDEV 1 for operating system updates. So, even if performance was not an issue, it always puzzled me that HP did not provide MPE/XL out of the box with the equivalent of VINIT's CONDENSE just to have a means to create the necessary contiguous free disk space. Many people experienced difficulty moving to 5.0 because they did not have any means short of a reload to create enough contiguous free space on LDEV 1.
Second, Posix compliance for MPE/iX 5.0 brought with it fork(). And I'm not talking about a utensil that you eat with, but rather a means of rapidly spawning processes that retain the environment of the parent. fork() requires chunks of contiguous free space. On badly fragmented systems, fork() will fail, causing your Web server, for example, to crash. Not nice.
When the clamoring for a fix got loud enough, HP did two things. First, the internal algorithm the file manager used to allocate file extents was altered to dis-favor LDEV 1. The theory was that over time, blocks of free space would be created on LDEV 1 by the gradual moving off of permanent storage to other drives in the system volume set. Of course on systems with two to four drives in the system volume set this could create a severe imbalance in disk I/O, but that is another article and, anyway, it is being "fixed." Allow me the smug observation, however, that if HP had simply retained the algorithm and user tuning capability of MPE/V, this would never have been a problem. But I digress.
Secondly, with MPE/iX 5.0, HP added the CONTIGVOL command to the VOLUTIL utility. Shades of VINIT's CONDENSE, CONTIGVOL can in many, but not all, cases be used to create sufficient contiguous free disk space on LDEV 1 for an operating system update (assuming, of course, you have "plenty" of free space in total on LDEV 1). CONTIGVOL will not move extents to other drives. What's more, HP said in a letter dated February 1, 1995, that it recommends CONTIGVOL "NOT" [emphasis HP's] be used as a disk management or defragmentation tool. Bottom line, it's taken us years to recover just a portion of the system management flexibility we had on MPE/V. -- John Burke