[Info-vax] Support of partitioning

[Stephen Hoffman]

On 2015-05-03 19:22:18 +0000, Snowshoe said:

> 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.

It's not at all magical.  It's hackish.

>> How difficult is it for VMS to support partitioning ? What is involved 
>> in providing support ?

I would not expect to see this prior to the new file system that VSI 
has reported, and potentially not even then — they have a large list of 
work, and much of that list will likely be prioritized well ahead of 
this work.

The bootstrap needs to account for the partitioning and instantiate the 
boot device with the proper offset and size.  This is the most complex 
part of the work.

The closest analog in the current OpenVMS implementation is probably 
SCSI sub-LUNs — these are the underpinnings around why SCSI devices 
were presented as DKA0:, DKA100:, DKA200:, and not DKA0:, DKA1: and 
DKA2:.

At run-time, it's just another disk device, though with a partition 
offset and partition size stored in the UCB.   Bias the address that 
the user has requested before accessing the device, and bias the 
address values when presenting addresses to the user.

> 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.

The run-time portion of this work is comparatively trivial.  It's the 
primitive file system and the rest of the bootstrap that's slightly 
more complex, as well as keeping the storage devices associated once 
you've got OpenVMS bootstrapped.  You probably want all the devices to 
dismount when the base device is dismounted, for instance.  You'll also 
need to implement tools for creating, re-sizing, verifying and deleting 
partitions.

>> From the ODS point of view, isn't just a question of remapping blocks ?

ODS-2 and ODS-5 are multi-partition overlays in the current design.  
Currently, between two and five partitions get overlaid, depending on 
the specific partitioning in use.   You likely do not want this 
overlay, either.  You want ODS-2 and ODS-5 to be occupants of the 
partitions, not overlays.

>> 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 ?

Correct.  Conceptually, it's trivial.

> 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.

LD processes the file extents, and uses that data to access the 
underlying disk storage via the device driver ALTSTART interface.

>> 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's surmountable.

> 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.

The existing OpenVMS I/O environment does not particularly have a 
concept of a "sub-unit device" or a "partition device", and it'd be 
typical to expect to have the partitions dismount when the underlying 
disk dismounts.   There are some other wrinkles.

> 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.

It'll involve backing out the existing hackery, to start with.  
Existing tools will need work, as well.  ANALYZE/DISK would not 
currently know what to do when presented with the underlying device 
rather than the disk partition, for instance.

>> 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.

Correct.  It's adding or subtracting the offset, and using the 
partition size rather than the volume size.

> 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.

OpenVMS can already mount specific foreign file systems; see the ODS-3 
and ODS-4 support for details.  Yes, it's custom ACP work, or some XQP 
re-work, potentially some work in MOUNT to automatically identify the 
file system, and also work in some other pieces and tools.  MOUNT is 
the easy part.   Dealing with an ACP or an XQP is slightly more effort.


-- 
Pure Personal Opinion | HoffmanLabs LLC