HP-UX B.10.20 I/O Error

[Todd Dilley]

I have been thrown to the curb on this one. Company is still running an HP 9000 with HP-UX B.10.20. They plan on removing the system in August, but until that time they still need it. They noticed a file on the system that was not getting backed up. When I try to copy the file from the fs it comes up and says I/O error. I have very limited experience with Unix to say the least. I ran fsck and it recovered a couple bad blocks. Is there a way to fix this file, or copy it?

Thank you in advance for any help!

[Michael Steele_2]

Please provide the following:

-cat /etc/fstab | grep -i fs (* name of fs *)

-lvdisplay /dev/vg??/lvol?? (* as provided in first column of /etc/fstab file for your problem 'fs' *)

-bdf fs (* problem fs *)

[Todd Dilley]

Thank you for the quick response!

/dev/vg01/u1 hfs rw,swid,nolargefiles 0 2

LV Name /dev/vg01/u1
LG Name /dev/vg01
LV Permission read/write
LV Status available/syncd
Mirror copies 0
Consistency Recovery MWC
Schedule parallel
LV size (Mbytes) 4000
Current LE 1000
Allocated PE 1000
Stripes 0
Stripe Size (Kbytes) 0
Bad Block on
Allocation strict
IO Timeout (Seconds) default


Kbytes used Avail used mounted on
/dev/vg01/u1 4007201 3304054 302426 92% /u1

[Patrick Wallek]

Check /var/adm/syslog/syslog.log and see if you see any errors there from the time that you last attempted to copy the file.

If you are seeing I/O errors this does not necessarily bode well.

[Todd Dilley]

We usually backup the file and the last time it ran successfully was last Friday. i was trying to copy the file to make a backup of it prior to restoring the file from backup. I have deleted the file, and doing a recovery on it right now. Will the fsck command mark the bad blocks so it does not right to them again?

[Bill Hassell]

fsck is not a bad disk fixer. It's job is to correct directory and inode numbers that have become corrupted or not updated correctly. An I/O is simply a bad spot on the disk. You will see this by reading the entire disk with dd like this:

dd if=/dev/rdsk/ctd of=/dev/null bs=1024k

where: ctd is the controller, target and device name such as c0t6d0 or c4t3d1. The command will fail when it hits the bad spot. As Patrick points out, this is a bad sign. The disk is going bad and will never get better. Eventually it will crash and you will lose everything on the disk, possibly everything in the entire vg01. Make a complete backup of *all* the lvols in vg01. You should have lots of error messages in /var/adm/syslog/syslog.olg showing you the bad disk.

If the data on vg01 isn't important, you can ignore the problem.

[Michael Steele_2]

This is an hfs file system. You will have to repair by using an alternate super block that you find in /etc/sbtab.

use

#fsck -b

[Torsten.]

If the system finds a bad block during write it does bad block relocation and use another block. But if it finds a bad block during read, the file is gone since you don't have a mirror copy. Check the disk if it has more errors, replace if needed and restore your data.