[Info-vax] Support of partitioning

[Snowshoe]

On 5/3/2015 1:21 PM, JF Mezei wrote:
> It is well known that VMS doesn't support partitioning has has had to do
> some black magic to pretend to support it.
>
> How difficult is it for VMS to support partitioning ? What is involved
> in providing support ?

The way I see it, at least for the old style partitions, a very simple 
"file system" could be "mounted", providing disk ranges (the partitions) 
that could be fed to a slightly modified LDDRIVER.  LDDRIVER then mounts 
the partitions as logical disks.  "Slightly modified" in that it maps 
ranges of disk blocks directly as presented by the primitive partition 
mount, not to a file on an ODS-2/5 volume as it does now.

I don't know the new GPT partition system, I assume it's similar, just 
more complicated.

>  From the ODS point of view, isn't just a question of remapping blocks ?
>
> So for a 7000 block partition starting at physical block 2000, when ODS
> wants to access block 0, it gets remapped to read physical block 2000 ?
> Is that how it works ?

Just use the LDDRIVER to do this  This is what LDDRIVER does. I don't 
remember if LDDRIVER handles non-contiguous files (making the mapping of 
the logical block access to the physical disk block more complicated). 
See above.

> I take it that at boot, the system would have to look at all physical
> drives to create virtual disk devices for each partition ?  Is that a
> big problem ?

It would be done at mount time.  A special mount/extension of mount 
would interpret the partition bits, whether the way I described or some 
other way.

A (properly) partitioned system disk is a whole 'nother can of worms. 
It must involve a lot of work (by VSI), much like adding GPT to ODS-2/5 
in the first place.

> Are there performance issues with IOs first going to the virtual disk
> driver that works out the virtual disk block into physical disk blocks
> and then issues IO to the physical driver ? Or would the two be combined
> into the same code/driver ?

If using the LDDRIVER or similar, the mainline path would just have to 
add an offset to the block# before passing the IO onto the physical disk 
driver.

=====

Speaking of all this, is there any use for support of alternate file 
systems in VMS (ext2/3/4, NTFS, FAT-x or whatever)?  In theory you could 
$ MOUNT one of these file systems and create/delete/copy files directly 
to/from the alternate file system, without using special
software (which usually can only copy files to/from a foreign file 
system).  I guess on VMS it would involve writing an ACP for the file 
system.