[Info-vax] ISAM on disk layout. Was: Re: HP wins Oracle Itanium case

[Johnny Billquist]

On 2012-08-29 18:14, abrsvc wrote:
> On Wednesday, August 29, 2012 11:45:02 AM UTC-4, Paul Sture wrote:
>> On Tue, 28 Aug 2012 20:12:38 +0000, glen herrmannsfeldt wrote: > Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote: >> On 2012-08-28 16:58:35 +0000, Bob Koehler said: > >>> Blows away folks when I access a keyed-indexed file "sequentially". > >> You're either being humored with that "blown away", or you're >> discussing this with folks that are ignorant of how databases work. >> What you're discussing goes back to the S in the IBM Indexed Sequential >> Access Method ISAM scheme, and which well predates RMS. > > And which uses IBM CKD (Count Key Data) disks where keys are written > before data blocks on the disk. You can ask the disk hardware to search > for a block with a given key, or with a key greater than or equal to the > given key. (The index is sorted to make the search easier.) > > ISAM files are also interesting in that the index contains disk block > addresses such that the files are unmovable. (There are special programs > that know how to backup and restore an ISAM f
ile, and rewrite the index > as needed.) This highlights a problem with RMS. On mainframe systems I was used to placing files carefully on disk, aligning by cylinder etc. I cannot remember whether the compatibility mode RMS utilities (IFL - Initial File Load and friends) could do file placement, but once FDL came along you could. However, another black mark for BACKUP/IMAGE was that it doesn't honour FDL file placement. If you were going to use FDL's file placement functionality, you had better not use BACKUP/IMAGE. We chose to ignore file placement in favour of the convenience BACKUP/IMAGE brought us for defragmenting disks. -- Paul Sture
>
> The "smart" controllers also made file placement less important.  The UDA50 was the first to "re-order" disk reads such that the heads moved in one direction to collect the data rather than the "normal" in-out movement.  I recall testing this with the 780 and confirmed that for small reads (1-3 blocks) the Unibus outperformed the Massbus even though the transfer rate for the Massbus was twice as fast.

The UDA-50 (and similar controllers) don't just change the order in such 
a simplistic way as just doing the movement in one direction.
It's trying to optimize for the lowest total head movement, but at the 
same time not doing excessive reordering to a point where one requests 
gets starved out.

Older controllers didn't even have a queue for requests, so it was all 
up to the OS, which could implement any kind of optimization. So, from 
that point of view, the smart controllers are not really that much 
better, if you have good software.

The really tricky parts, which the OS can't do, is when you start having 
a rather undefined geometry on the disks. You do not need to have the 
same number of sectors on all cylinders. Further from the hub of the 
disk, you can squeeze in more sectors per cylinder, starting to make it 
hard to figure out how much your heads are going to move, and 
controllers started exposing an interface which just states the block 
number, and not the full cylinder/head/sector thing.
The next stage made it totally impossible for software to compete, and 
that was bad block remapping at the hardware level. Disks started to be 
presented as always without errors, and the disk and controller remapped 
bad blocks to replacement blocks. At this point it becomes impossible 
for software to say where a block actually resides on the disk, and you 
cannot know how the heads will move. The controller can still know, 
though...

And this is where we are today.

	Johnny