I am trying to find documentation for dmpfs.
I understand that /dev/vx/dmp/* /dev/vx/rdmp/* can be removed without affecting the volumes.
when the files are removed, I wonder what are the impacts. For example,
any pointers would be appreciated.
you are right that directories can be removed without affecting volumes, even after directories are removed, there will be no impact to iopolicy & still multipaths will be available, simple reason for that is, the configuration is available in the kernel. What happens with cleaning directories is only on disks or filesystem & not in the kernel hence deleting the device tree doesn't make any operational impact.
below tech article describes the correct device tree cleanup procedure
The files in /dev/vx/[r]dmp/* are access points to the DMP block and raw pseudo devices used by VxVM. There are similar to other devices files.
As they are files, they can be manually removed BUT exercise CAUTION as if something tries to access the device file and it has been removed, the device will not be accessible, which could have a knockon affect of failed disk, Disk Group not-importable, inaccessible data etc.
If the device is already in use, then it will have already opened the file and the file handle will be handled in-kernel. However if you stop using the device and try to re-use it, it will fail if the device file has been removed.
I am wondering to fully understand the impact of removing these files. what exactly would be using these files?
you mentioned that they are opened in the kernel. how does dmp uses these devices? for example, which kernel module would depends on the /dev/vx/[r]dmp/* devices?
At a high level - If using Storage Foundation then you are likely to be using VxVM Logical volumes. When you send i/o to these volumes, VxVM works out which disk has to service the i/o. VxVM then sends this i/o the to DMP meta device for that disk. DMP then works out which path to send it to and handles any errors on the way.
The DMP meta devices are required
this is my understanding as well. but how often does vxvm needs to access the DMP meta devices with I/O policies set to round-robin? if the device can be removed and cleared, I would imagine that it is not often. It puzzles me exactly when would vxvm volumes access DMP devices. ie. when does it need to find out which path to send to
The i/o policy is not really in the same context as the accessibility of these files. These files provide a doorway into the DMP metanodes which are essentially a representation of a disk and all of its paths.
When a new disk device has ben detected by VxVM, it will build new DMP device files
As VxVM starts up it will open the various pseudo devices and some of this will be available in-kernel. VxVM will use these devices for i/o if the i/o is to be serviced by that device. When the i/o reaches the metanode, the DMP module will determine which path to use, taking into account the i/o policy that has been set.
Going back to your original query, are you facing an issue or is this just informational ?
the reason I am asking about this is. if i have to clear the content of /dev/vx/[r]dmp/* and rebuilt them, I would like how safe it is to do so and what are the impact.
what is the worst that could happen?
what operations should be avoided during the period of removing these files and rebuilding them.
wheather it would definitely not affect currently mounted filesystems.
I administer VCS clusters with SF. so I would like to know the impact. I have a hard time finding any documentation out there explaining the risks of removing dmp devices.
If the DMP meta node is accessible when VxVM needs to open and use it then the device will be inaccessible (failed disk etc). This also applies if there are multiple paths as the DMP metanode is the gateway to those paths.
The DMP metanode will be built as part of a VxVM device scan, if the devices are accessible.
Have you had a look at TECH78463 in Gaurav's post? It says:
The following procedure is a Symantec Technical Support tested procedure to perform a device tree cleanup with EMC storage, EMC Powerpath and Volume Manager in the configuration on a Solaris system, where required.
It explains that you should freeze the Service Group or entire system and then 'stop vxesd daemon to ensure that no device discovery is taking place by Volume Manager' .
This step will prevent VxVM from scanning until such time as device cleanup is completed and you start the daemon again.