[SunHELP] Strange problem after powerfail

[Katherine Strojny]

Michael Karl wrote:
> i have a strange problem after customer mistake during powerfail.
>
> Now the UE450 with Solaris 2.6, SDS 4.1 with product-patch and a
> CMD-Hardware RAID doesn't start with a filesystem-problem.
> Via remote I started the fsck and got following messages:
>
> # fsck /dev/md/rdsk/d10
> ** /dev/md/rdsk/d10
> ** Last Mounted on /raid0
> ** Phase 1 - Check Blocks and Sizes
> INCORRECT BLOCK COUNT I=23360094 (2576 should be 1232)
> CORRECT? y
>
> 524326659 BAD I=23424216
> 541103364 BAD I=23424216
> 524325636 BAD I=23424216
> 507351045 BAD I=23424216
> 524061444 BAD I=23424216
> 507284229 BAD I=23424216
> 507611910 BAD I=23424216
> 540838405 BAD I=23424216
> 557484035 BAD I=23424216
> 540771588 BAD I=23424216
> EXCESSIVE BAD BLKS I=23424216
> CONTINUE? n
>
> "/dev/md/rdsk/d10" is a metadevice (concentration of d0 and d1:
> two raid5-sets) and the filesystem was generated via growfs,
> because "d0" is four years old and "d1" was build in 2001.
>
> I don't understand the "EXCESSIVE BAD BLKS"-error.
> I tested with format (analyse and test) both raid5-sets and have no
error.
> I got no messages ... any hits ?

 Sun's SA-238 (Sol 8) course manual says this about excessive bad blocks:

"This error occurs when too many (more than 10) data blocks for an inode
are out of the range of possible block numbers for the file system.
Answering y to the CONTINUE prompt instructs fsck to continue checking but
the error is not cleared until an fsck session completes without error."
(p. B-4)

So the inode is pointing to data blocks that don't exist, and you're not
going to lose anything that wasn't already lost by correcting it.
('format' won't help because it works at a lower level--disk sectors, as
opposed to the file system structure which contains the data blocks that
fsck is talking about.)

This error occurs in the Phase 1 of fsck (inode integrity check).  It
sounds like you could run into related errors in later phases or in
repeating the check.

The question I would want to keep in mind is whether the inode in question
is assigned or free (anyone?  does fsck bother checking for bad block
numbers on free inodes?), and if it's assigned, which file is it assigned
to and are you going to have to restore the file.

HTH

-k