Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

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

Created: 10 Jan 2014 • Updated: 25 Sep 2014 | 10 comments

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.

Operating Systems:

Comments 10 CommentsJump to latest comment

Gaurav Sangamnerkar's picture

Hi,

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

http://www.symantec.com/docs/TECH78463

G

PS: If you are happy with the answer provided, please mark the post as solution. You can do so by clicking link "Mark as Solution" below the answer provided.
 

TonyGriffiths's picture

Hi,

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.

cheers

tony

IdaWong's picture

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?

regards,

Ida

TonyGriffiths's picture

Hi,

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

cheers

tony

IdaWong's picture

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

TonyGriffiths's picture

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 ?

thanks

tony

IdaWong's picture

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.

regards,

Ida

TonyGriffiths's picture

Hi,

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.

cheers

tony

IdaWong's picture

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?

Marianne's picture

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.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links