Hi Eric! On Mon, 1 Mar 2010, Eric Sandeen wrote: > > Sorry for the delay, here's the (good) 2.6.32 result: > > > > # /usr/bin/time bash -c "dd if=/dev/zero of=/mnt/large/10GB bs=1M count=10000 && sync" > > 10000+0 records in > > 10000+0 records out > > 10485760000 bytes (10 GB) copied, 46.3369 seconds, 226 MB/s > > 0.00user 14.17system 0:59.53elapsed 23%CPU (0avgtext+0avgdata 6224maxresident)k > > 0inputs+0outputs (0major+1045minor)pagefaults 0swaps > > > > To summarize: > > > > Bad: 2.6.18-164.el5 (CentOS) > > Bad: 2.6.18-164.11.1el5 (CentOS) > > Bad: 2.6.18-190.el5 (RH) > > Good: 2.6.32 > > Good: 2.6.33 In the meantime I've also reproduced the problem on another machine with a Red Hat 5.5 Beta (x86_64) installation and decided to open a bug on RH's bugzilla: Bad ext4 sync performance on 16 TB GPT partition https://bugzilla.redhat.com/show_bug.cgi?id=572930 > Thanks, I'll have to investigate that. I guess something may have gotten lost > in translation in the 2.6.32->2.6.18 backport..... Did you come up with anything I could test? Is anyone else able to reproduce the problem? -- Karsten Weiss -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
