Bug 690237

Summary: gfs2: creating large files suddenly slow to a crawl [rhel-5.4.z]
Product: Red Hat Enterprise Linux 5 Reporter: RHEL Program Management <pm-rhel>
Component: kernelAssignee: Robert Peterson <rpeterso>
Status: CLOSED ERRATA QA Contact: Red Hat Kernel QE team <kernel-qe>
Severity: high Docs Contact:
Priority: urgent    
Version: 5.7CC: adas, bmarzins, dhoward, jkortus, jpirko, jwest, liko, msantang, pm-eus, rpeterso, rwheeler, ssaha, swhiteho
Target Milestone: rcKeywords: ZStream
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: kernel-2.6.18-164.35.1.el5 Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-05-05 14:38:13 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 683155    
Bug Blocks:    
Attachments:
Description Flags
The 5.4.z crosswrite patch none

Description RHEL Program Management 2011-03-23 16:53:06 UTC
This bug has been copied from bug #683155 and has been proposed
to be backported to 5.4 z-stream (EUS).

Comment 3 Robert Peterson 2011-03-23 19:29:36 UTC
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.

Comment 4 Robert Peterson 2011-03-23 19:30:27 UTC
Patch provided; setting devel_ack.

Comment 8 Phillip Lougher 2011-03-31 13:21:34 UTC
in kernel-2.6.18-164.35.1.el5

linux-2.6-fs-gfs2-creating-large-files-suddenly-slow-to-a-crawl.patch

Comment 10 Jaroslav Kortus 2011-04-27 19:39:55 UTC
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

Comment 12 Eva Kopalova 2011-05-05 13:02:28 UTC
    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.

Comment 13 errata-xmlrpc 2011-05-05 14:38:13 UTC
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