Disk in OFFLINE STATUS

[smsc_1]

Hello all,
I tried to install a new hard disk, used controller doesn't matter because I have the same issue with a different controllers (like EVA or an old HSZ80), so I think the issue was on OpenVMS 8.3-1H1.

The problem is when I phisically remove the disk and using
show device d
I always see the device in OFFLINE status
I also tried following command under MC SYSMAN:
IO AUTO

But the device was still there.

How remove the OFFLINE device without reboot the system??

Thanks!

[Robert Gezelter · Accepted solution]

smsc,

If I understand your posting correctly, then the answer is: The device cannot be removed from the IO database. It will continue to be there.

IO AUTO adds devices, it does not subtract them.

Is there a particular problem with the device showing in the SHOW DEVICE display, albeit with a status of OFFLINE.

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

If removing the disk device unit is critical requirement (and you can't just ignore this and leave the disk unit marked offline), you must reboot the system or (if the disk is cluster-served) the whole cluster.

Disk devices and most other non-cloned devices will and always have required a reboot to clear.

There is no mechanism to unwind any I/O activity and unload most devices, nor most device drivers.

Cloned devices do tend to have support for this, but disks aren't cloned devices.

[Jon Pinkley]

smsc,

As Bob says, this is a limitation of the VMS disk IO system. It bugs me too, as I end up having many "zombie" $1$dga disk once they have been presented and added the the IO database. For cloned devices that are not MSCP served, for example LD devices created from other disk, that isn't a limitation, they can be deleted without any visible trace.

Rob Brooks or Jur van der Burg can probably give a better explanation as to the reasons for this design "restriction".

Jon

[Hoff]

>Rob Brooks or Jur van der Burg can probably give a better explanation as to the reasons for this design "restriction".

There's no mechanism for "device garbage collection."

To implement "device garbage collection" here, HP OpenVMS Engineering would need ensure the device is inactive and that all I/O requests (IRPs) are returned from the XQP or ACP or where the driver has stored them, that new I/Os are blocked and not in flight, that the device is not going to toss an interrupt at the host (or that any arriving interrupts are sent to the blackhole or to the new-device path), and that the various I/O (UCB, VCB, potentially the DDB) and higher-level data structures (volume locks, MSCP connections, channels) are all correctly detected and unwound and deleted. The drivers and the I/O subsystem do not currently provide a mechanism for ensuring that for disks.

Feasible? Likely yes. Cloned devices do have most of this capability now, but then they're also usually not cluster-served devices, and the drivers tend to have explicit support for unwinding the activity. Justifying the implementation and testing effort for garbage collection for MSCP and disks and for TMSCP and tapes is going to be a project in itself, regardless.

[Jur van der Burg]

One of the reasons this can't be done without a major overhaul of VMS is for example mscp serving. If a device is served, and would then be removed it would be left on another node. Of course one could design a method to do that, but I think given the current VMS' state its unlikely to happen.

LD does not have this issue because it's a cloned device, and it does NOT allow mscp serving (on purpose!).

Jur.

[smsc_1]

Thanks for clarification (@ all).
So, the final solution will be reboot the machine. And for sure there's no particular problem with the device showing OFFLINE status, it's just a cosmetic thing!

[smsc_1]

Closing thread and assign points!

Thanks again to all!

[Hoff]

Oh, yeah, forgot one: you also need to deal with MSCP and TMSCP server versions that are running on other boxes in the cluster that don't have the "quiesce and unwind" support.