Would restart of syncer repair kernel disperate mnttab?

[Ralph Grothe]

Hi,

I seem to have some inconsitency between kernel and actual mount state.

The problem arose when we had a defunct root disk replaced a couple of weeks ago.
I managed to cleanly lvreduce all mirrored LVs in vg00 that had LEs on the defunct disk.
Ultimately however I was hindered to vgreduce because there was one LV that was not mirrored and had LEs left soley on the defunct disk.
The only solution that worked in the end was to enforce a SCSI reset by replacing the disk by a new one even though the last LV was still mounted under /opt/patrol.
Only then was I able to lvreduce to 0 LEs (the lvremove still kept hanging) to finally cleanly vgreduce.
After that I had the mirrors of the other LVs re-lvextend'ed again.
I didn't care for the lost mount because the data therein wasn't that important.

However, now I cannot get the mount removed from /etc/mnttab.
That's why a bdf emits something stupid like

# bdf /opt/patrol
bdf: /opt/patrol: I/O error

since the mountpoint had been rmdir'ed by me

# ll /opt/patrol
/opt/patrol not found

I'm convinced that this will disappear as soon as I reboot the machine, but this I cannot do until the next maintenance intervall.

I understand that some monitoring scripts (n.b. I have no access to the managment station that originate them) are stumbling over this bdf.

I thought that maybe meanwhile (until next reboot) restarting the syncer and in-between removal of /etc/mnttab would help.

But I don't dare to stop the syncer, since I haven't done it manually before (i.e. executing /sbin/init.d/syncer), and I have no notion of any detrimental side effects this might have.
Mind you, the box is a production server.

How can I resolve this?

[T G Manikandan]

If you want that to be removed from mnttab

just remove the /opt/patrol entry from /etc/fstab.
Then do a
#mv /etc/mnttab /etc/mnttab.old
#mount -a


Revert

[Ralph Grothe]

nope, no avail

# rm /etc/mnttab && mount -a >/dev/null 2>&1 && grep patrol /etc/mnttab
# bdf /opt/patrol
bdf: /opt/patrol: I/O error
# grep patrol /etc/mnttab
/dev/vg00/lvol11 /opt/patrol vxfs delaylog 0 0 1049988632

[James Murtagh · Accepted solution]

Hi Ralph,

All the syncer will be doing in respect to the mnttab is reading the vfs stuctures in the kernel and writing the results back. You can see the active vfs structures using q4 :

q4> load struct vfs from rootvfs next vfs_next max 50
loaded 10 struct vfss as a linked list (stopped by null pointer)
q4> print -tx vfs_name
vfs_name "/dev/root"
vfs_name "/dev/vg00/lvol1"
vfs_name "/dev/vg00/lvol5"
vfs_name "/dev/vg00/lvol8"
vfs_name "/dev/vg00/lvol4"
vfs_name "/dev/vg00/lvol7"
vfs_name "/dev/vg01/lvol2"
vfs_name "/dev/vg01/lvol1"
vfs_name "/dev/vg00/lvol6"
vfs_name "-hosts"

Only a reboot will clear the vfs structure that references your dead mount. If you want to get round this you could kill the syncer and restart with the -s option so as to not update the mnttab, but note the warnings on the syncer manpage - this is strongly discouraged!

Cheers,

James.

[T G Manikandan]

Did you remove the entry from /etc/fstab before doing a mount -a after rm mnttab?

[Ralph Grothe]

Of course did I comment the staled mount in fstab prior to "mount -a", even though so imbecile I must appear ;-)

# grep patrol /etc/fstab
# /dev/vg00/lvol11 /opt/patrol vxfs delaylog 0 2

[Ralph Grothe]

James,

thanks for clarifying the reason and confirming the need of a reboot.
I also agree that the discouragement of syncer's usage with the -s switch in the manpage is stressed for good reason.

I guess the initial cause of the struggle is owe to an obsolete patch level as far as the LVM cumulative patch is concerned.

[Ralph Grothe]

As for my subject line,
rest assured how emarrassed I feel for misspelling DISPARATE!