Inconsisrtency with mnttab entry.

[Senthil Kumar .A_1]

Hi,

We have come across a strange issue.

# bdf /u01/app/oragesp/admin
Filesystem kbytes used avail %used Mounted on
/dev/vg38/lvol1 512000 133236 355107 27% /u01/app/oragesp/admin
# bdf /dev/vg38/lvol1
Filesystem kbytes used avail %used Mounted on
/dev/vg38/lvol1 4096000 18142 3822992 0% /u01/app/oragesp/admin
/dev/vg01/lvol10 512000 133236 355107 27% 993 94691 1% /u01/app/oragesp


# ls -id /u01/app/oragesp/admin
4 /u01/app/oragesp/admin


Basically we encounter a error while umounting /u01/app/oragesp/admin, we get the following error..

# umount /dev/vg38/lvol1
umount: cannot unmount /u01/app/oragesp/admin : Block device required
umount: return error 1.

INFERENCE: The system is not able to umount, understandably, because it looks though it is already umounted.. Also from the test we performed.. "ls -id /u01/app/oragesp/admin" gives a inode number "4" whereas it should have been "2" if it were mounted. secondly.. see our first 2 BDF outputs above.. though we query same FS, we get 2 diffent answer, reemphsizing our findings. That means.. the /etc/mnttab is showing the FS mounted though it has already been unmounted.

Now my question is , is there a workaround to solve this issue without rebooting.

Regards,
Senthil Kumar .A

[Steven E. Protter]

Shalom Senthil,

You might be able to use lsof to identify the process that is making the mnttab entry and kill it.

If this is coming from an incorrectly configured automount setup, it may return after boot.

fuser -cu /mountpoint

will help identify processes on the mountpoint

fuser -cuk /mountpoint will make then all disappear. Be careful, your system can be disrupted by the latter command if you nail the wrong process.

SEP

[Devender Khatana]

Hi Senthil,

The mnttab will be always recreated when using mount or unmount commands. move file to some alternate name and then mount/unmount any existing file system and see of it works.

HTH,
Devender

[Arunvijai_4]

Hi Senthil,

This thread may help you,

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=623324

-Arun

[Senthil Kumar .A_1]

Thanks for everyone for there time spent on this issue. When my Pal logged in a call to HPRC, it seems the only solution was to reboot the cluster node. Not too sure why this could have happened.

[Siju Vadakkan]

This issue was resolved after rebooting the box