| If you managed to get a TRANSPORTABLE disk to work in a NOTRANSPORTABLE
slot, it was only because at one time that disk had been initialized as
NOTRANSPORTABLE. If the metadata is not on the media, we don't allow a
NOTRANSPORTABLE disk to go online.
** You're playing with fire here. **
In its life as a TRANSPORTABLE disk, some of the old metadata could have
been altered. This could cause unpredictable results when you use it as a
TRANSPORTABLE disk.
The VMS filesystem attempts to use blocks near the directory (near the
center) first, so the blocks at the end that "no longer exist" are among the
last blocks used. Thus, your observation that things appear to work.
However, because the controller is now using some disk space for its own
purposes, if this disk ever goes back to a TRANSPORTABLE slot, some of the
user space has been altered.
Your expectations of disaster are not out of line.
|
| When you VMS init a disk it fixes up the SCB [sorta superblock for the Unix impaired]
and at that time the disk size is "frozen".
If you later expand the size by nefarious means VMS wont care in the least
as long as you keep using the filesystem. If you circumvent the filesystem
the "extra" space can be gotten at.
[To prove this idea of a reduced device try a backup/restore of a small
DUAx device to a larger variant]...
Initializing a large device then reducing its apparent size is caught by
MSCP with an invalid LBN when VMS tries to access the data off the end.
So you could! create a device with a filesystem that has inaccessable
files this way [why, oh why?].
The problem [or fire danger] is that when the unit is converted from
with-metadata to without, the metadata is not destroyed. Consequently you
could flame-it then resurect it as a phoenix in another life.
If you are really adventurous you could move devices between disparate
controller architectures also. :-)
BTW, none of the above is advised, supported... its sure to lead to disaster.
|