On Thu, 12 Feb 2004, The awesome and feared Spider commented thusly, > > Just dont think that you know the best and dont criticise others > > openly, learn a lesson for once in your miserable life and read about > > a bit before criticising other peoples comments and people themselves. > > *Sigh* > As I tried previously, I attacked your statement, not the person behind > it, and your decision to portrude this to private mail in an effort to > spark responses portrays you fairly negatively. Well calling me "greentoe", is not attacking statements is it. I privately mailed you because I dont want to clatter this list with OT discussions. Instead you go and pst this to a public list. Well if this is the way you want publicity then you shall have it.
> But, instead of using google to dig up the first and shiniest link, > using the popularity gained on /. and blogging, I'd suggest you actually > take the time to lean back and read lkml and other lists where the > actual responsetimes are shown. You wanted facts and I gave you facts, what is a better benchmark that to see how a kernel compile takes on different platform. There were other tests done and after all a benchmark is a benchmark, the fact that this link is popular changes nothing, even if it were less popular the benchmark statys the same. Well I read the article you pointed too but the review himself never recommend that ext3 be used in any situation correct? For exery aspect ie low cpu, high throughput he recommended every other journalling FS other than ext3. So if this so called ext3 is so good why the review not mention it? > When it comes to regards of benchmark quality, I wouldn't call something > a "benchmark" when the sk. "benchmark" doesn't document what kernel it > is that is being "benchmarked". ( Note for the readers, according to > referenced article (by grendel) comments, it was kernel 2.4.3-xfs that > was tested, which would put it about 3 years ago. ) > Now, if you can show me a throughput vs. latency benchmark during a > paralell ( ncpu * 2 ) C++ compile on a memory-strained system (48 Mb RAM > or so), where you'd actually measure filesystem performance and not > BufferCache performance (that, means "RAM" performance). How many machines in the real life pratically fit your specification, it would be hard getting a 2.6 (even a 2.4)kernel running on a 48mb machine, there would be a lot of swapping going on to render any file system bechmarks test pointless. Every decent server that has a lot of file access going is going to have at least 256mb ram. So your example maybe good for a theretical situation, but it is of little practicle use in the real world. ext3 and ext2's problem is that they dont scale well, btree based FS like reiserfs scale very well. So that is why they are superior to ext2 in every way. I would have been happier if the folks at redhat had decided to make ext3 a completely rewritten file system rather than trying to ensure ext2 compatibility. Grendel -- Hi, I'm a signature virus. plz set me as your signature and help me spread :) -- [EMAIL PROTECTED] mailing list
