fsck

[Linda Lux]

I have a secondary mirroring process that mirrors the application database to a backup K box. The /dev/vg04/area1 is split, and in the script
fsck -p /dev/vg04/area1b
runs
Since I upgraded to the 11.0 OS, this has failed, and I have to manually run the fsck. The mirroring process runs anywhere from 5 to 7 times during the day, and the command fails at least 3 to 5 times.
I have tried other fsck commands, still get the same reults.
Any help?
Linda

[Helen French]

What type of error you get? What type of file system is this? The -p option in 'hfs' and 'vxfs' fsck has different functions. Are you running the same command manually?

[Linda Lux]

The file system is hfs - my application database has to be on that type of system.
I manually run
fsck /dev/vg04/area1b, and have to answer a bunch of fix and clear with "y".

[Jeff Schussele]

Hi Linda,

First off I always use -F fs_typ - so use -F hfs in the command - just to be safe.
Next I would look at using -P (cap P) as this will allow cleanly unmounted filesystems to proceed on unchecked. Then also consider -q (quiet mode) as this will fix the safe stuff and avoid the annoying interactivity when it's not necessary.
Then the final thing to consider is if you ALWAYS answer yes & never have problems, then use -y - but it has to be noted that this can hammer you if you do happen to have loads of nasty trouble. But hey it's a copy - right?

My 2 cents,
Jeff

[Helen French]

Again, check what and why fsck reports consistency errors on the file system? If you can correct it, that would be your best choice.

Also, if you want, you can automatically answer "Yes" to *ALL* user prompts given by fsck during that session with '-y' option. This is not a recommended method though.

[A. Clay Stephenson]

My first cut at this would be to try running this application on a vxfs filesystem. I know what you said but truthfully the details of the filesystem should be completely hidden from the application. It should have know way of knowing that this is a vxfs filesystem. A possible exception would be very old statically linked code. The fsck's would be much more reliable and you could also use vxfs snapshot mounts which would require absolutely no fsck's and would not incurr the large i/o hit of re-mirroring.

[Bill Hassell]

For HFS filesystems, the busier they are when the split occurs, the more 'yes' answer you have to give to correct link counts and connections. I would never mount any filesystem with the -f (force) option. The probability of a system panic like freeing free inode or freeing free frag is very likely, and while it is a copy, all it takes is one bad filesystem to bring down the entire computer. Generally speaking, auto-answering yes to everything is OK since fsck will stop when a real problem shows up. And all of this assumes that you applied the complete HWE/QPK patch bundle to your 11.0 system before going into production.

[Hemanth Gurunath Basrur]

Hello Linda,

Refer to the foll. link. Looks like you should have patch PHCO_28116. The old patch was PHCO_19673 and the superseded patch is PHCO_28116. Search for fsck_hfs in the link below.

http://www.software.hp.com/SUPPORT_PLUS/docs/QPK1100.html

HTH.

Regards,
Hemanth