Re: Desktop Filesystem Benchmarks in 2.6.3

[Mike Fedyk <mfedyk@matchmail.com>]

cami wrote:
>>> 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