This tip presents a solution to make CommVault 7SP2 data migration running properly on SLES 10 SP1.

For CommVault data migration we need DMAPI and XFS support coupled in the kernel which is officially built in/supported on SLEx 10 SP1 Linux, apparently it’s the only commercially supported Linux with this option. (Thanks!)

When we mount the xfs partition with this option drivers (kernel modules) get loaded in automatically:

sles10sp1:~ # grep xfs /etc/fstab
/dev/disk/by-uuid/841a8967-d904-427c-9042-b679f2a9af0e /data xfs logbufs=8,dmapi,mtpt=/data,quota,gquota 1 2

sles10sp1:~ # mount /data

sles10sp1:~ # lsmod | grep dmapi
xfs_dmapi 33688 1
dmapi 53672 1 xfs_dmapi,[permanent]
xfs 580728 3 xfs_quota,xfs_dmapi

The problem is that Commvault (Galaxy) looks for a device under /dev named “xfs_dmapi” which is named “dmapi” in SLEx 10 SP1. It’s not a big deal, we can just create a symbolic link to it but it will disappear at next reboot due to /dev is “tmpfs” since SP1!

There are plenty of ways to solve this problem but which is the one which won’t get overwritten by updates, portable and really the right way of doing this?

udev for the rescue! udev manages devices so we will create a simple rule to instruct udev to re-create the symbolic link every time the system boots.

sles10sp1:~ # cat /etc/udev/rules.d/999-udev-dmapi-commvault.rules
RUN+="/bin/ln -s /dev/dmapi /dev/xfs_dmapi"

Usually rules are more complex, describing which subsystem, which driver, module, etc. we are about to alter but this time we really do not need anything special just run a simple command. I decided to run the command last in the rules directory hence the numbering is high.

To read a bit more about this:
http://reactivated.net/writing_udev_rules.html

(Visited 1 times, 1 visits today)
Tags: ,
Category: SUSE Linux Enterprise Server, Technical Solutions
This entry was posted Wednesday, 30 January, 2008 at 12:07 am
You can follow any responses to this entry via RSS.

Comments

  • billdo says:

    CommVault File Archiver / Data Migrator is the only part of CommVault Galaxy aka Simpana that uses the XFS filesystem with the DMAPI hooks. We’ve been experiencing EXTREME performance problems to the point that the product is useless. This has existed since our initial install a few months ago.

    Is anyone here having the same problem? I’m assuming yes, because we’ve been told by CommVault support that the problem is because of the DMAPI interface. Right now we can only get recalls using File Archiver to perform at 20% of the rated speed of the drive. Yes, that’s correct, 20%.

    CommVault has had their top engineers and even their software developers looking at our environment for a month. Any one here having the same problem since Commvault has left us holding the bag? We’re running SLES 10 with the latest CommVault Simpana patches on all components. Perhaps someone has some sysctl changes that we can implement until CommVault starts really supporting their software on Linux?

    Thanks for any help!
    Bill Donnington

  • cscottselero says:

    Thanks for the post!
    One thing I came across while implementing XFS for File Archiver:

    Don’t forget to modify /etc/sysconfig/sysctl

    DMAPI_PROBE=”yes”

    Chris

  • variia says:

    Thanks for the hint!

    Ivan

  • Leave a Reply

    Your email address will not be published. Required fields are marked *