On 11/15/05, Dan Price <[EMAIL PROTECTED]> wrote: > On Tue 15 Nov 2005 at 03:50PM, Dennis Clarke wrote: > > I just saw this : > > > > fsck -F ufs -Y /dev/rdsk/c0t0** /dev/dsk/c0t0d0s0 > > < snippage > > > I did rerun fsck again and I get the same message over and over. I > > suspect that something else must be happening here. I may boot with > > the cdrom just to verify. > > Yes, there has been work done on fsck recently, in snv_22: > > 1260290 RFE: fsck error: UNKNOWN FILE TYPE describes multiple error conditions > 4836779 fsck requires multiple runs to clear up DUP or BAD blocks > 4845221 ufs/fsck can't handle filesystem name argument > 4857410 ufs_sync_indir() walks off the end of the i_ib array > 4872089 fsck almost always reports FREE BLK COUNT(S) WRONG IN SUPERBLK > 4890510 fsck can't properly recover the filesystem > 5086715 ufs fsck has memory leaks > 6175186 fsck should not need to be run multiple times > 6208131 fsck needs to be able to recover filesystem problems > (nbfree,ndir,nifree > ,nffree suspect) > 6312941 PSARC 2005/044 UFS fsck rerun messaging > 6312946 PSARC 2005/045 UFS fsck verbose option > 6312949 PSARC 2005/051 UFS fsck automated search for a backup superblocks > 6312954 PSARC 2005/043 UFS newfs/mkfs superblock calculation options >
whoa .. that is a lot of work done. > So, it's possible you've found a bug or just an existing problem > in fsck? It could just be my boot drive dying also :-) > I've BCC'd the author of these changes; hopefully he'll also respond. I don't want to cause work for anyone. Let me run a surface scan of the disk with analyze and see if the disk is shot. If all is well then I will restore from ufsdumps and see what fsck says again. If we still get complaints then perhaps there is a problem. This is on UltraSparc by the way although I expect the code to be the same regardless. Dennis
_______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org