Showing results for 
Search instead for 
Did you mean: 

how come /dev/vx/dmp/* can be removed while the volumes are mounted?

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,

  • does it impact iopolicy?
  • can it still find multiple paths?
  • etc...

 any pointers would be appreciated.

10 Replies

Hi, you are right that


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


Hi, The files in


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.




Thanks Tony, I am wondering

Thanks Tony,

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?



Hi, At a high level - If


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



Hi Tony, this is my

Hi Tony,

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

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

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.



Hi, If the DMP meta node is


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.





so would you feel confident

so would you feel confident that it is safe to remove all the /dev/vx/[r]dmp/* and rebuild them on a production system with vxfs filesystems mounted?

Have you had a look at

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.