Just as an FYI my preferred order for fscks # fsck -F vxfs /dev/vx/rdsk/DG_name/VOL_name Intent LOG ONLY replay
# fsck -F vxfs -o full,nolog -n /dev/vx/rdsk/DG_name/VOL_name FILE SYSTEM AND METADATA STRUCTURES ONLY - NO INTENT LOG - a LOOK at what will happen remembering there ARE transactions in the intent log. # fsck -F vxfs -o full -n /dev/vx/rdsk/DG_name/VOL_name ALL FILE SYSTEM AND METADATA STRUCTURES - a LOOK at what will happen You can mount READ ONLY for a quick look - or to backup crucial data - remember unplayed transaction in the intent log # mount -F vxfs -o ro /dev/vx/dsk/DG_name/VOL_name /mnt You can ff / ncheck to match file names to inodes removed in above fsck -o full # ncheck -F vxfs /dev/vx/dsk/DG_name/VOL_name # ff -F vxfs /dev/vx/dsk/DG_name/VOL_name This is usefult to cross reference file that will be removed in the full fsck - these are in the fsck output above. Check what is in the intent log # echo "fmtlog" | fsdb -F vxfs /dev/vx/rdsk/DG_name/VOL_name Remember fset 1 is the VxFS metadata, fset 999 is user data. Collect a METASAVE - use the binary in /opt/VRTSspt/FS/MetaSave # fsck -F vxfs -o full,nolog -y /dev/vx/rdsk/DG_name/VOL_name # fsck -F vxfs /dev/vx/rdsk/DG_name/VOL_name ALL FILE SYSTEM AND METADATA STRUCTURES - WITH REMOVING STUFF IF THERE ARE ERRORS OR # fsck -F vxfs -o full -y /dev/vx/rdsk/DG_name/VOL_name ALL FILE SYSTEM AND METADATA STRUCTURES - WITH REMOVING STUFF IF THERE ARE ERRORS FMTLOG - Internal Technote 251996 -----Original Message----- From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of Thomas Graham Sent: Wednesday, 3 March 2010 4:25 PM To: William Havey Cc: veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] inode invalid?! I see, so checking lost and found dir is an important step On Tuesday, March 2, 2010, William Havey <bbha...@gmail.com> wrote: > The purpose of fsck is to make a file system mountable. If this requires > putting some unaccounted for file system block into the lost+found directory, > leaving the admin to decide what to do with the block, so be it. A file > system simply can not guarantee data integrity under every conceivable > circumstance. That's why redundancy is built into either the hardware, if the > situations cause is hardware failure, the array provides a good copy, or the > storage software, through mirroring. > > > On Tue, Mar 2, 2010 at 7:18 AM, Thomas Graham <lktho...@gmail.com> wrote: > > But would it remove some blocks which contain data? > > On Tuesday, March 2, 2010, William Havey <bbha...@gmail.com> wrote: >> A file system check of VxFS should be very quick. Read the Intent Log >> records, write them out to disk, done. Do the backup after fsck. >> >> On Sun, Feb 28, 2010 at 9:31 PM, Thomas Graham <lktho...@gmail.com> wrote: >> guys, I am using veritas cluster file system, and currently CFS is >> marked as dirty and I have to take the whole FS offline to do fsck >> scanning. Anyone know if there have any risk to hit inode if I do >> backup during inode invalid situation? >> >> -- >> Thomas G Lau >> Tel: 93239670 >> _______________________________________________ >> Veritas-vx maillist - veritas...@mailman.eng.auburn.edu >> http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx >> >> > > -- > Thomas G Lau > Tel: 93239670 > > -- Thomas G Lau Tel: 93239670 _______________________________________________ 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
