Re: [squid-users] anyone compared comparison of reiserfs vs ext3 on linux recently ?

attached mail follows:

Thanks for all the responses.

This was the level of detail that helps me think about the issues rather
than blindly follow the pack.

For those who mentioned, google, yes I did that previously and saw lots
of refs to Joe's work but never enough about ext3, but thanks for taking
the time for the steer's.

Let you know when I am up to my ears in crocs :-)

In message <AA7A72A46469D411B8B300508BE3295005431BCA@desi2>,
sean.upton@uniontrib.com writes
>An informal observation: I think cache size would likely be a factor too,
>but likely in the extreme case only. I was running another application that
>stores many small files districtued across many nested directories (bushy
>filesystem organization, similar to Squid, but likely a more extreme case)
>and found that with high hundreds of thousands or millions of files, the
>system (Dual XeonDP 2.0, 4GB Ram, RAID 10 across 8 10k U160 disks) slowed to
>the point the system was largely unresponsive when accessing anything in
>that filesystem (there were 1.2 million files before I decided I needed to
>try ReiserFS instead, though I haven't gotten to the point of comparing at
>this scale yet). With this many files, accessing metadata seemed
>problematic. Even doing an ls in the root of this fs was painful. It may
>well be though, that at even the most reasonable maximum size you would ever
>see a cache, ext3 may scale just fine.
>
>By way of background reading, I have found Von Hagen's _Linux Filesytems_
>book a rather good, fairly up-to-date read, at least perhaps a good guide to
>making educated guesses in this case.
>
>Sean
>
>-----Original Message-----
>From: Joe Cooper [mailto:joe@swelltech.com]
>Sent: Thursday, January 02, 2003 12:45 PM
>To: Mika Aleksandroff
>Cc: squid-users@squid-cache.org
>Subject: Re: [squid-users] anyone compared comparison of reiserfs vs
>ext3 on linux recently ?
>
>
>Mika Aleksandroff wrote:
>> On Thu January 2 2003 21:04, Mike wrote:
>>
>>>Can anyone proffer an opinion about the merits of using reiserfs over
>>>default linux filesystems ext3 for a squid server ?
>>
>>
>> Joe says reiserfs rules. Joe rules. Trust Joe. :-)
>>
>> http://list.cineca.it/cgi-bin/wa?A2=ind0203&L=squid&P=R40022
>
>Thanks for the vote of confidence, Mika. But I will temper it by noting
>that Duane obtained different results in some benchmarks a few months
>ago, showing that ReiserFS was slower on his hardware than ext2 or ext3.
>
>I suspect CPU:disk ratio to be the determining factor, because ReiserFS
>is harder on the CPU than ext2 or ext3. Duanes test machines had plenty
>of disks (6 x 10k RPM, I think), but not a lot of CPU horsepower (2 x
>500MHz, maybe?), whereas my machines are more likely to have fewer disks
>(always 3 or fewer, as that's all our 1U chassis will support--I don't
>keep any 2U systems on hand, as they are too expensive to stock) and
>more CPU (always more than 1GHz these days). So, if CPU is your
>limiting factor, ext2 or ext3 might be a better option. AUFS is also
>very CPU hungry, so it will behave differently on a slower CPU with more
>disks.
>
>I still choose ReiserFS for all of my cache_dirs, because I know it is
>fast and extremely reliable for Squid workloads, and my experiences with
>ext3 for Squid have always been negative. All of the benchmarks I've
>done on ext3 have ended in kernel oopses, though I assume those problems
>have been fixed by now. My tests were done on kernel 2.4.9 (plus all of
>the Red Hat patches at RPM release -31 and a few others), so I'm sure a
>year+ of development has fixed those issues. ext2 is not an option for
>me, as the fsck time and flakiness of an unjournalled FS would be
>extremely problematic for our clients.
>
>So, as always, if you /must/ know for sure which is faster, then you'll
>need to test it on your own hardware to see. Most folks will see no
>difference one way or another, as modern hardware is extremely oversized
>for most Squid installations. You simply can't buy or build a Squid
>machine with modern components that is capable of supporting less than
>two full T1 links with plenty of headroom to spare.

-- 
Mike Cudmore
tel : 0208 850 5066
mob : 077 8067 4387
Macon Services terms of business apply.