I've had ext3 corruptions of note.. Running ext3 on squid's caching
partition (expensive hardware + raid1+0 setup), what i'd have was if
any proccess wrote to that caching partition, it would lock up the
process.. even an rm on any file inside that partition would lock up
rm.. after shutting down the machine, and _reformatting_ that partition
with mkfs, it *still* done the same thing.. After getting fed up being
unable to resolve the problem,
Did you post to the ext3-users list on this?
Live/Production machines leave very little time for proper debugging.. (so to answer your question, no..)
I would still suggest you post to the list to see if there is a solution. That allows you to try it on another machine, or do something different if you setup a new production machine.
Were your processes stuck in "D" state, or did you have high systems times?
Even with the machine rebooted, i was still experiencing the same thing..
That doesn't say much. If you have corruption on disk, you might get this.
If so, you could have configured squid to put fewer files in each directory, or use the htree patch (for 2.4 kernels) or it's in by default in 2.6.
Doesnt make much sense, even when reformatting the disk with ext3 again, proved to be useless.. After about 20 seconds with squid running, the same issues would arise.. The machine was up for about 40 days before the issues occured..
What kernel version was this on?
Mike
