Which file has the bad block?

[Angela Swyers_1]

I was doing a backup and it is complaining about a bad block. How do I tell exactly what file contains that block?

I/O error: [block 9638460]: count 64512

[Sunil Sharma_1]

I am not sure if there is anyway to check which file has bad block. You try to find out which disk has badblock and replace it.

Sunil

[bhoopathi_1]

Do
$ cd
$ file `ls -lR`|more

this would show what are the file types (inside the directory). And any file its not able to read will give error.

One more way of trying would be,
$ cd
$ du *

this would give error for the subdirectory inside which there is some problem. You can boil down to the exact directory or file name.

I am not sure if the above two ways would exactly solve your problem, but its worth giving a try.

[Stephen Keane]

Was the bad block message refering to the output media, or the source you were trying to backup?

[Bill Hassell]

There is no easy way to determine the file that is affected. If the error message refers to the filesystem (and not the tape), you can read the man pages for fsdb but you will need advanced training on the VxFS filesystem layout. Essentially, you will have to locate the inode tables and look for the block count. However, the error message seems like it points to tape rather than disk. Verify your filesystem with:

dd if=/dev/vgXXXX/rlvolYYY of=/dev/null bs=256k

If you see no I/O error messages, the error message refers to the tape. Fill in XXXX with the VG name and be sure to use the "r" logical volume for speed.

[TwoProc]

I'm afraid that Bill's right - you're going to have to copy each file that you suspect over to /dev/null to see which one generates the read error.

If you suspect that the file is "somewhere" within a whole mount point and you can only narrow it down to a whole mount point - you can cpio up the whole thing to /dev/null..
(see below)

- cpio will generate the error string "Corrupt Block" or "corrupt block" when reading a block in a file that can't be read. I remember seeing this very text in my database backups years ago (before Omniback rescued me with better software) and shreiking in horror like I'd just seen a ghost.

use the following to check out a mountpoint...

cd /mntpointa
find . -xdev -depth | cpio -oBdvmuxc > /dev/null 2> /tmp/logfile &


After it's done look for the error with vi.

open the file with
vi /tmp/logfile
type
:set ignorecase [Hit Enter ]
/corrupt [Hit enter ]

Should take you right to the file that's bad
(unless you've got file names or directories with the string "corrupt" as part of the name).

Ok, let's all now together wish that the bad is just a throwaway logfile and not a vital database file...

... W I S H ... W I S H ...
( think happy thoughts )
... W I S H ... W I S H ...

:-)

[H.Merijn Brand (procura]

did you try an fsck?

Enjoy, Have FUN! H.Merijn