OpenSolaris

Printable Version Enter a New Search
Bug ID 4648917
Synopsis certain TOP-level VOP's are not recognized by the lockfs protocol
State 10-Fix Delivered (Fix available in build)
Category:Subcategory kernel:ufs
Keywords -f | -h | 5.10 | 5.5.1 | 5.7 | 5.8 | 5.9 | EIO | EIO_vfs | NULL | T_DONTBLOCK | VBAD | forced | hard | ip->i_ufsvfs | lock | lockfs | panic | s9-reviewed | ufs-forced-umount | ufsvfs | umount
Responsible Engineer Prabahar Jeyaram
Reported Against 5.7 , 5.8 , 5.9 , 5.10 , 5.5.1
Duplicate Of
Introduced In solaris_2.3
Commit to Fix s10_56
Fixed In s10_56
Release Fixed solaris_10(s10_56) , solaris_9u7(s9u7_07) (Bug ID:2103455)
Related Bugs 4052200 , 4134299 , 4377012 , 4450382 , 4455182 , 4477339 , 4522842 , 4625036 , 4652746 , 4751446 , 4919475 , 4919540 , 6238102
Submit Date 7-March-2002
Last Update Date 7-March-2002
Description
 xxxxx@xxxxx.com 2002-03-07

see comments.
Work Around
 xxxxx@xxxxx.com 2002-03-07

forced umount case: stop using ufs forced umount

lockfs -h/umount case (aka. cluster failover):

If you've actually suffered from this, you could change
the cluster script "/opt/SUNWcluster/bin/scnfs" to
use the vxfs unmount logic for UFS FS as well,
as vxfs does't have a forced umount (till 3.4)
and hence all procs accessing the FS will be killed before
the unmount of the vxfs FS will take place.

 xxxxx@xxxxx.com 2002-03-14

As coredumping procs are the most common trigger of this panic
during forced umounts/failovers, another possible workaround would be
to disable application coredumps via limit(1) in vulnerable
environments.

 xxxxx@xxxxx.com 2003-08-28

or easier disable user process coredumps via coreadm(1M) systemwide 
"coreadm -d process"

 xxxxx@xxxxx.com 2003-12-04

or instead umount(1M) -f use lockfs(1M) -h /filesystem to hard lock the
filesystem, then wait 60sec and the umount(1M) the filesystem. 
the 60 sec grace period should enable ongoing VOP's  to finish.
Comments
N/A