We have a Sun Server running Solaris 10 and Veritas Cluster Server. The RAID Volumes in the Server (/ , swap, opt, var, usr) are managed by VxVm and UFS is grown on all these volumes.
Lately the system has been crashing due to an inconsistency in the opt filesystem. Upon reboot we did a fsck on the the opt multiple times and booted the system to multiuser mode. But again the system is crashing once the cluster is ok. The following is the panic message:-
I dont see any error coming from VCS. But after we did fsck on opt and repaired it, and when VCS was started few resource wasnt online. But the problem is hanging of the system. Everytime the OPT goes to "needs sync" state.
If you require any specific output i can produce immediately. As you can see below its unable to read from the opt and it crashes. And opt is managed by VxVm with UFS grown over it.
panic[cpu1]/thread=3000d19a6c0: alloccgblk: can't find blk in cyl, pos:0, i:377, fs:/opt bno: 300
Also i forgot to mention that there is no scsi errors or anything from the internal disks, please see the iostat output:-
It sounds like this is a server crash issue (ie: the root issue is with the /opt ufs filesystem, which is on a VxVM volume, not with VCS itself) - moving to from Cluster Server to Storage Foundation forum (although from the messages provided so far, it appears the error may be related to the ufs fs rather than the volume)
For the server crash issue - do you have crash dumps enabled? If so, please provide the following mdb output for more information about the crash:
# mdb -k unix.0 vmcore.0
refer to the mdb manpage for additional options.
Regarding the supposed opt size discrepancy - the sizes are consistent - with -t option, the length is the 6th field (as seen in the header key)
V NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPE
PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE
SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE
so based on your output:
"UFS is grown on all these volumes."
Not a good idea and not supported.
You cannot grow or shrink any volume (
swapvol, and so on) that is associated with an encapsulated root disk. This is because these volumes map to physical partitions on the disk, and these partitions must be contiguous..