[Info-vax] Valid disk types for SIMH?

[Bob Eager]

On Mon, 23 Nov 2009 08:29:32 -0800, Galen wrote:

>> ls -l  provides the file size in terms of number of bytes used. Not
>> sure which incantation of ls s needed to get allocated blocks.
>>
>> when you INIT, i believe that by default, it places some of the
>> structures in the middle of the disk.
>>
>> So the container file of say 1 gig would have some structure probably
>> written at the start and its middle, but nothing after. So the file
>> system would think the logical end of file is the highest byte written,
>> hence near the middle of the disk.
> 
> If you have a simh Vax already running VMS you could use it to pre-
> initialize a disk volume (and its underlying Mac OS X disk file) with /
> INDEX=END. That would put INDEXF.SYS at the logical end of the disk,
> forcing OS X to extend the Mac file to the size you specified in your
> simh SET command.

Not necessarily. The point is that files on some UNIX file systems are 
allocated sparsely - a block is not allocated to the file until data are 
written to it. One can create (say) a 1GB file, and write the very last 
block to it, only. It then shows up in 'ls' output as a 1GB file. It is 
actually occupying just one block. Any attempt to read the unallocated 
blocks is allowed, and returns a block of zeros.

In VMS terms (if supported!), INDEXF.SYS would have two entries. The 
first would be a 'dummy' one saying that all but one logical blocks were 
unallocated; the second would point to the one 'real' block.

Sounds inefficient, and with ODS-2 etc. it probably would be; it works OK 
on UNIX file systems that were designed for it.

So, to get a properly allocated container file for SIMH, one needs to do 
INIT/ERASE. Seems a good idea, and I think I'll do it from now on.

-- 
Use the BIG mirror service in the UK:
 http://www.mirrorservice.org