App team requested more space on /backup. Allocated 300 gigs more to localdg. While expanding both the volume and its fs using vxresize (my colleague fired it from VEA), it just got hung. The probable reason might be - fsadm requires some free space in the background to carry out the expansion. but the file system was full and there was no space available. Ideally speaking, vxresize should have checked this thing first and should have aborted the operation before starting it if there wasn't enough space. Apparantely this didn't happen.
The server, vxvm, vxfs everything was still functioning except /backup. Any process trying to access /backup will not respond. df -k, ls, cd on /backup will hang. ps -ef | grep vx showed fsadm hung. Couldn't kill it with -9 as root. There were other processes started by cronned database scripts trying to access /backup. Even those couldn't be killed. In all - anything related to /backup just got hung and couldn't be killed. Logged the call with Veritas. They advised to reboot. We rebooted about 2 hours ago and verified that the volume was enabled/active with 300g added to its size. This means fsadm did go through successfully finally. When I tried to mount it gave me message that it might be corrupted. fsck gave the map and summary messages. Based on Veritas recommendation (I should hear back from them in about an hour), we will either run fsck with or without risk. We might use vxdump before fsck if it involves risk. We will vxrestore if fsck corrupts the data. Mike/Darren - thanks for your advice though. I've been member of this group for a while now, and I really appreciate the help you guys provide to this mailing list. cheers Ketan On 7/24/07, Darren Dunham <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] # fsck -F vxfs -n /dev/vx/rdsk/localdg/localdg_vol01 > pass0 - checking structural files > pass1 - checking inode sanity and blocks > pass2 - checking directory linkage > pass3 - checking reference counts > pass4 - checking resource maps > au 7572 emap incorrect - fix? (ynq)n > au 7572 summary incorrect - fix? (ynq)n > fileset 1 iau 0 summary incorrect - fix? (ynq)n > OK to clear log? (ynq)n > sanity checks/updates have not been completed - restart? (ynq)n > > Shall I go ahead with fsck? Will it cause me lose my data? I can't say for certain that all your data will be there, but the problems that are shown are rather innocuous. It's not like it's showing disconnected inodes or anything, just some map and summary updates. While a comparison against a backup would be thorough, in most cases I'd probably just let the fsck run and go on. I don't expect any significant problems from those messages. That said, I'd attempt to understand what happened to cause the need of the fsck. Simple crashes or power failures shouldn't do that. -- Darren Dunham [EMAIL PROTECTED] Senior Technical Consultant TAOS http://www.taos.com/ Got some Dr Pepper? San Francisco, CA bay area < This line left intentionally blank to confuse you. > _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
_______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
