Karsten Weiss wrote: > 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, and thanks for double-checking upstream. >> 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? I'll look into this... > Is anyone else able to reproduce the problem? Since it's not an upstream problem, this issue is probably best discussed in the RHEL bug, now. Thanks, -Eric -- 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
