mount problem when trying to take a snapshot

[Nickolas A Gray]

When trying to take a file-system snapshot, the mount command could fail with the following error message:
# mount -F vxfs -o snapof=/dev/vg00/vxonline /dev/vg00/vxbackup /vxbackup
vxfs mount: /dev/vg00/vxbackup is already mounted,
/vxbackup is busy, or allowable number of mount
points exceeded

Looking in the /etc/mnttab shows that the filesystem is not mounted. I have seen a patch for this in 10.01 adv. but nothing else. Has anyone else seen this. supposedly it has to do with.

A snapshot could not be mounted if a process was waiting arbitrarily long for a file record lock. An application using lockf() or fcntl() to get file record locks, and holding the locks for a long period of time, could prevent from mounting a file-system snapshot.

[A. Clay Stephenson]

Hi Nickolas,

I routinely use snapshot mounts daily on quite a few filesystems and I never see this error.
I have done this under 10.20, 11.0, and 11.11.
If you have lsof I would run it on both /dev/vg00/vxbackup and /vxbackup.

Also, what version of HP-UX are you running and is this JFS Vrsn 3.1 or 3.3?

[Sanjay_6 · Accepted solution]

Hi,

Take a look at the threads below,

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=1c2f4cee1477c08a93/screen=ckiDisplayDocument?docId=200000014667872

http://us-support2.external.hp.com/cki/bin/doc.pl/sid=1c2f4cee1477c08a93/screen=ckiDisplayDocument?docId=200000049195192

Hope this helps.

thanks

[MANOJ SRIVASTAVA]

Hi Nicholas

It looks as if some one is using that mount. Try doing a fuser -c /vxbackup or a fuser /vxbackup to get the process holding the sub directory . You can try killing that porcess and retrying the mount command. Some times if the subdirectory is in the PATH options even though it is not mounted u will never be able to mount unless u free the point.

Manoj

[Nickolas A Gray]

Thanks for the responses. This is 10.26 sort of. It has been modified as per contract with HP after that. Sanjay, the second link did it. I am pretty sure this is the problem. I should have pointed out that this is a scripted backup that runs at night and since I have been working on the problem I rewrote the script and added and fuser (along with other commands) to the part of the script right before it fails. Unfortunately there is no one using the mount point or filesystem. That is why it was such a strange problem. I am not the end user, but I will have him add lsof to the script and see what happens when it fails

Thanks again, I will post again when I get more data or a resolution

[Nickolas A Gray]

Clay, this is part of the problem. Since I am on the development/support team I have the same system under my desk. I can't get it to fail that way. I am not sure what JFS this is but I think 3.3

[A. Clay Stephenson]

Okay Nicholas, this now rings a bell. I had a similar problem with OmniBack Pre-exec scripts which did snapshot mounts. Every once in a while, the Disk Agent would fail with something like 'filesystem '/snapxxx' not found' yet when OmniBack aborted and the Post-exec did not do a umount the snapshot was there. The problem wound up being that the mount(2) system call does not update mnttnb until the syncer daemon runs. There was eventually an OmniBack patch for this that delayed starting disk agents until mnttab was updated. I wound up writing a Perl Script with sockets to synchronize this before the patch was released.

Clay