fsck Phase 5 (free blocks) cannot read 4 blocks.

[ErickS]

Running SCO Unix 3.2 v4.2 (character-based) on Compaq Proliant with 2 mirrored SCSI 2GB drives on "Smart Array" controller. Worked great so far.

Suddenly rebooted, no apparent reason. No messages.

fsck seemed to get things cleaned up until the second disk volume, which holds our important data. fsck consistently reports, in Phase 5 (check free list bitmap), that it cannot read 4 specific blocks. Always same block #'s. Concludes with "15885 blocks missing".

fsck man page says this is serious and not to proceed until it's cleaned up.

I shut down and powered off, then re-started and ran the Compaq diagnostics. All seems fine with CPU, memory, drive array controller and that 2nd drive. It passed all seek and read tests just fine.

But unix's fsck keeps complaining about those 4 blocks.

I have read that mounting a "bad" file system on unix can spread the corruption, so I am not mounting it until I can be sure it's safe.

Does anyone out there have experience with this kind of situation, or know someone who does?

I have until Sunday night to try to recover my people's work before I have to resort to re-formatting the drive and installing the last backup. That would forfeit a lot a recent work, just before deadline.

Thank you.

 

[pcunix]

Hmm. I have no idea what the Compaq diags really do, and it's complicated by the mirrored drive.

I would *expect* that the RAID controller is smart enough to notice a problem with the second drive and just take it off-line until you replace it, so we'll assume the problem isn't there.

Do the bad reads show up in /var/adm/messages as disk block read problems? If they do, even though you've run the Compaq diagnostics, I would still run the SCO badtrk utility (single user mode).

But- if they do not, then this is a case of the inode table pointing to disk blocks that are beyond the physical size of the drive. That can happen from somone shrinking a partition in divvy (divvy allows you do do that even though it's a recipe for disaster), If that's it, you have a mess that can ONLY be cleaned up by recreation of the filesystem and restoration of data.
Tony Lawrence
SCO Unix/Linux Resources

http://pcunix.com

tony@pcunix.com