OpenSolaris

Category
   utility
Sub-Category
   filesystem
Description
   If a filesystem contains duplicate blocks, and one of the blocks is claimed by an inode with a link count of zero, the fatal error BAD STATE 0x5X TO BLKERR can appear (where X is 2, 4, or possibly 8), and the fsck will terminate without doing further repairs.
inode.c:blkerror() should probably just mask out the INZLINK and INCLEAR bits  in the switch statement. e.g. 
switch (statemap[ino] & ~(INDELAYD|INZLINK|INCLEAR)) {
 
 case FSTATE:
 statemap[ino] = FCLEAR;
 return;
 
 case DFOUND:
 case DSTATE:
 statemap[ino] = DCLEAR;
 add_orphan_dir(ino);
 return;
 
 case SSTATE:
 statemap[ino] = SCLEAR;
 return;
default:
 errexit("BAD STATE 0x%x TO BLKERR\n", statemap[ino]);
 /* NOTREACHED */
}
but this would have the additional effect of making the SZLINK be legitimate on entry to blkerror, which is currently not the case.
Frequency
   Always
Regression
   No
Steps to Reproduce
   I do not have a small filesystem image that displays this problem, but it is likely I could construct one with fsdb. Let me know if that would be helpful
Expected Result
   fsck fixes the filesystem by duplicating the bad blocks or clearing the inodes
Actual Result
   fsck terminates with BAD STATE 0x52 TO BLKERR
Error Message(s)
   
Test Case
   
Workaround
   Using clri to clear one of the duplicate inodes allows fsck to complete
Submitter wants to work on bug
   No
Additional configuration information
   This problem was actually encountered on a solaris 10 06/06 sparc system, but I confirmed that it is present in the current opensolaris fsck source code.

Using clri to clear one of the duplicate inodes allows fsck to complete

N/A