The short version of this story is that I had a motherboard whose hard drive controller went bad. Got a new box and popped in the old hard drives. There's a couple hundred files that have "input/output" errors. I know that often indicates hard drive failure. Multiple tests tell me that the hard drive is fine and the errors are related to the bad motherboard.

The problem is that I can't delete the bad files. Some GUI programs won't even list the contents of a directory that has one of the bad files. I have a vague notion that I have to delete the inodes of the affected files, but I don't know enough about filesystems to know how to do that. "fsck.ext4 -y" says the disk is clean, and a non-destructive "badblocks" says the disk is fine, too. "ls -il" in an affected directory lists just a question mark for the inode of an affected file, so I definitely don't know how to delete the inode if I can't even find it's number.

I can restore the affected files from backups, but need to be able to delete them first. Any ideas? Thanks all.

--chriscrutch

If you have backups of the drive contents (good job, many don't) why don't you just re-format the drives and restore from your backups. It'll be quicker in the long run than mucking about trying to fix each individual problem. Just a thought.

Hmmmm. To be completely honest, I hadn't considered that. Any time I hear "re-format" I get nervous a bit. But maybe that's the way to go.

I'd love to learn more about filesystems and linux, though. I've been running Linux on my main computer full-time for over ten years now, but there's always something new to learn. I'll keep plugging and asking for a little bit, before I resort to a full wipe and backup. Thank you for the suggestion. It's probably what I'll end up doing.

--chriscrutch

Are they "normal" files, or all in lost+found ?.
Personally I never trust a filesystem that has had an "event" - trash it and start over from that backup.

All "normal" files. None of them are in lost+found. And I can understand the fear of trusting the filesystem, but the slightly longer version of the story is that I had two HDs in the old computer that had the same problem, thought it was a drive issue, replaced BOTH drives, and ended up in the same situation. The chances of having FOUR hard drives all fail in the same way seems pretty remote, so I don't think it's REALLY a filesystem issue, but rather an issue with the now replaced motherboard.

--chriscrutch

It's a filesystem issue. Might have been caused by that m/board, but it's broken.
Open a bug and get the devs to tell you what debug data they need.

You need to include the "-f" option to force a check of a filesystem that is not marked "dirty".