[Info-vax] Out of diskspace :(

[Johnny Billquist]

On 2012-05-19 12:08, Paul Sture wrote:
> On Sat, 19 May 2012 09:42:01 -0700, hb wrote:
>
>> On May 19, 5:38 pm, Johnny Billquist<b... at softjar.se>  wrote:
>>> I would not expect VMS home blocks to be located on different blocks
>>> depending on the size of the disk. You learn something every day.
>>
>> Usually the home block is in the second logical block: LBN 1. This LBN
>> is called the primary home block. If the primary home block is not found
>> (corrupted or overwritten by whatever), secondary home blocks are
>> searched at different LBNs of the disk. The secondary home block LBNs
>> are derived from the size of the disk. This is called the secondary home
>> block search sequence.
>>
>> ODS2/5 for OpenVMS/I64 uses a GPT (GUID Partitioning Table ) which
>> occupies at least LBN 0 and 1. So there are no primary home blocks for
>> these disks.
>>
>> Also, according to the "VMS File System Internals" book, the file system
>> must be able to allocate two good home blocks. It's not explained how
>> the second good home block is found. Home blocks are in the VBNs
>> 2,...,cluster_factor*3 of INDEXF.SYS. For a valid home block in LBN 1
>> one could get another home block from INDEXF.SYS without depending on
>> the disk size. But it seems the file system rather looks for another
>> good home block on the search sequence than trusts what it finds at LBN
>> 1, which makes sense to me and which may explain "not finding the home
>> block" after the disk size changed.
>
> Thanks.  I have a feeling that one of the error messages I saw indicated
> that the system couldn't find the _alternate_ home block.
>
> Here's part of a post I made on 3-Apr-2012:
>
> http://bit.ly/KkWoiN
>
> -----------
> Newsgroups: comp.os.vms
> Von: Paul Sture<p... at sture.ch>
> Datum: Tue, 3 Apr 2012 14:23:10 +0200
> Lokal: Di 3 Apr. 2012 13:23
> Betreff: Re: how to extract and install content from vms073lp.zip
>
> <snip>
>
> That's how I understand it too.  In the SimH context, I accidentally
> changed the value of RAUSER=n by factor of 10 for an existing disk and
> when I tried to mount it from VMS, unsurprisingly I got a message about
> the bitmap being corrupt.
>
> I've never seen a message about BITMAP.SYS being fragmented before :-)
> -----------

But BITMAP.SYS being "corrupt" would be totally expected, since it was 
created for the disk matching one size, and now the disk is another 
size. I would expect it to be possible to still mount the disk, although 
you might need to forcefully tell mount that it's ok with this discrepancy.
In fact, nothing is really corrupt, it only looks that way because there 
are disk blocks existing which are not at all present in the BITMAP.SYS.

	Johnny