[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Q] Do you trust fsck?



Box with Redhat 7.1 and kernel 2.4.20 has a hardware RAID (about 750 gigs data) attached via an Adaptec 29160 LP card...

I began seeing numerous SCSI errors in my logs for our external hardware RAID and input/output errors on test attempts to copy files via cp. Rebooted and immediately saw the errors as the disk was initially accessed by the Adaptec driver. The RAID controller did not report any problems and when I swapped cards, those errors stopped.

However, fsck.ext3 (1.27) immediately detected errors.

At first, it didn't seem too bad, about a few dozen inodes with illegal blocks, but then it got to reporting duplicate/bad blocks, probably a few *thousand* of them. It pointed out hundreds of files that shared blocks, which apparently it cloned.

At the end, it claimed despite all those errors, all was well and considers the system clean.

The initial SCSI errors occurred during a backup and the backup program had a number of files to go to finish. After the fsck, the backup program claimed to have about 800 fewer files to finish than before, implying that these files disappeared during the fsck (and that was just a portion of the disk).

The question is how do I know to trust fsck? What exactly does it mean that a file shares blocks with other files? How does fsck know file the block really belongs to or could it actually mean files are corrupted and fsck is letting them get by?

What I am asking is should I trust fsck's apparent success or should I choose to reformat and restore?
--


Maurice Volaski, mvolaski aecom yu edu
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]