This bug has been copied from bug #683155 and has been proposed to be backported to 5.4 z-stream (EUS).
Created attachment 487125 [details] The 5.4.z crosswrite patch The 5.6.z crosswrite patch did not apply to 5.4.z. Here is the replacement patch you need for 5.4.z.
Patch provided; setting devel_ack.
in kernel-2.6.18-164.35.1.el5 linux-2.6-fs-gfs2-creating-large-files-suddenly-slow-to-a-crawl.patch
No dramatical slowdown present in 2.6.18-164.36.1.el5 @x86_64 mkfs.gfs2 -b 1024 -j 6 -t jk:001 -O /dev/kerneltest/kerneltest kerneltest kerneltest -wi-ao 203.86G (14:35:15) [root@z2:~]$ cat 1024.dd.txt 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 17.3101 seconds, 60.6 MB/s 1000+0 records in 1000+0 records out 10485760000 bytes (10 GB) copied, 244.711 seconds, 42.8 MB/s 10000+0 records in 10000+0 records out 104857600000 bytes (105 GB) copied, 2793.9 seconds, 37.5 MB/s (14:35:17) [root@z2:~]$ cat 2048.dd.txt 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 12.3901 seconds, 84.6 MB/s 1000+0 records in 1000+0 records out 10485760000 bytes (10 GB) copied, 132.44 seconds, 79.2 MB/s 10000+0 records in 10000+0 records out 104857600000 bytes (105 GB) copied, 1445.85 seconds, 72.5 MB/s (14:35:22) [root@z2:~]$ cat 4096.dd.txt 100+0 records in 100+0 records out 1048576000 bytes (1.0 GB) copied, 8.09142 seconds, 130 MB/s (11:45:55) [root@z2:~]$ dd if=/dev/zero of=mount/file-10G bs=10M count=1000 conv=fsync 1000+0 records in 1000+0 records out 10485760000 bytes (10 GB) copied, 73.5685 seconds, 143 MB/s (11:47:20) [root@z2:~]$ dd if=/dev/zero of=mount/file-100G bs=10M count=10000 conv=fsync 10000+0 records in 10000+0 records out 104857600000 bytes (105 GB) copied, 777.386 seconds, 135 MB/s
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: GFS2 (Global File System 2) keeps track of the list of resource groups to allow better performance when allocating blocks. Previously, when the user created a large file in GFS2, GFS2 could have run out of allocation space because it was confined to the recently-used resource groups. With this update, GFS2 uses the MRU (Most Recently Used) list instead of the list of the recently-used resource groups. The MRU list allows GFS2 to use all available resource groups and if a large span of blocks is in use, GFS2 uses allocation blocks of another resource group.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-0489.html