cluster/gfs-kernel/src/gfs ops_file.c

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2006-10-27 16:22:18

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Bugzilla 211622 - Root issue is found and fix. Backout the workaround.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.27&r2=1.28

cluster/gfs-kernel/src/gfs ops_file.c

[fabbione]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	fabbione@sourceware.org	2008-01-30 09:05:57

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Whitespace cleanup

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.39&r2=1.40

cluster/gfs-kernel/src/gfs ops_file.c

[fabbione]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	fabbione@sourceware.org	2008-01-28 06:36:18

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	fix gfs for the removal of sendfile and helper functions
	
	Sendfile and helper functions have been removed in 2.6.24.  Migrate
	to using splice_read and generic_file_splice_read helper function.
	
	Signed-off-by: Phillip Lougher <phillip@canonical.com>

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.37&r2=1.38

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2007-06-17 03:35:03

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	bugzilla 244343:
	
	Backport RHEL4 gfs datasync patch to head.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.34&r2=1.35

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL5
Changes by:	wcheng@sourceware.org	2007-06-17 02:56:43

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	bugzilla 244134:
	
	Backport gfs datasync patch from RHEL4 to RHEL5 - sampled performance data:
	
	Throughput (lock_nolock)
	--- before ----         --- after ---
	Min 238.14 KB/s         Min 1.00 MB/s
	Max 238.14 KB/s         Max 1.00 MB/s
	Avg 238.14 KB/s         Avg 1.00 MB/s
	Latency Latency (lock_nolock)
	--- before ---------    --- after ---------
	Min 3805 usec 3 msec    Min 821 usec 0 msec
	Max 6043 usec 6 msec    Max 5466 usec 5 msec
	Avg 4182 usec 4 msec    Avg 1050 usec 1 msec

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.28.2.1&r2=1.28.2.2

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2007-05-24 22:34:54

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Apparently we can't remove these two methods from file operations table.
	Since gfs_read() had been changed to use do_sync_read() that requires to
	have aio defined in the file operations table.
	
	So vector read/write (implies NFSD) will be partially broken again after
	we put these two methods back.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.32&r2=1.33

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2007-05-04 14:49:36

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Temporarily disable GFS natvie AIO support since it currently breaks
	vector read-write (used by user mode application system call and NFSD).
	
	Will come back to fix this soon. Right now, application is expected to
	use posix AIO AIO call (done by libc AIO emulation).

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.31&r2=1.32

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	wcheng@sourceware.org	2007-01-17 22:30:13

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Remove aio code that was mistakenly added into stable cvs branch.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.16.6.2.2.6&r2=1.16.6.2.2.7

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	wcheng@sourceware.org	2006-11-17 20:39:24

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Bugzilla 216209: GFS has been splitting large writes into smaller atomic
	transactions. This would generate multiple aio completion calls (one
	for each transaction) that falsely notify application about data
	completion. Problem is reported by QA team while doing RHEL5 testing.
	
	Issue affects aio io size > 4MB.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.16.6.2.2.5&r2=1.16.6.2.2.6

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2006-11-17 20:33:16

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Bugzilla 216209: GFS has been splitting large writes into smaller atomic
	transactions. This would generate multiple aio completion calls (one
	for each transaction) that falsely notify application about data
	completion. Problem is reported by QA team while doing RHEL5 testing.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.14&r2=1.16.2.15

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL50
Changes by:	wcheng@sourceware.org	2006-11-17 20:26:28

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Bugzilla 214274: GFS has been splitting large writes into smaller atomic
	transactions. This would generate multiple aio completion calls (one
	for each transaction) that falsely notify application about data
	completion. Problem is reported by QA team as data corruption.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL50&r1=1.28&r2=1.28.4.1

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL5
Changes by:	wcheng@sourceware.org	2006-11-17 19:49:00

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Bugzilla 214274: GFS has been splitting large writes into smaller atomic
	transactions. This would generate multiple aio completion calls (one
	for each transaction) that falsely notify application about data
	completion. Problem is reported by QA team as data corruption.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.28&r2=1.28.2.1

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2006-11-17 16:15:32

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Bugzilla 214274: Oops... only directIO has this issue - buffer IO should be
	fine. Revert buffer io changes.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.29&r2=1.30

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2006-11-17 05:00:57

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Bugzilla 214274: GFS has been splitting large writes into smaller atomic
	transactions. This would generate multiple aio completion calls (one
	for each transaction) that falsely notify application about data
	completion. Problem is reported by QA team as data corruption.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.28&r2=1.29

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	wcheng@sourceware.org	2006-10-24 03:35:11

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Bugzilla 211622: GFS1 will asserts at xmote_bh() if DLM grants SHARED
	lock to direct IO's DEFERRED request. Add LM_FLAG_ANY
	to direct read to allow relaxed state and change direct
	write to use EXCLUSIVE lock.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.26&r2=1.27

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2006-06-07 14:06:11

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Move gfs_fsync() lock state back to LM_ST_SHARED based on yesterday's phone
	discuss.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.13&r2=1.16.2.14

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2006-06-02 04:56:55

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	RHEL4 defaults nfs export to "sync" so nfsd would invokes nfsd_sync_dir()
	that eventually calls gfs_fsync() with filp set to NULL. In lehman patch,
	I obtained inode location from filp, not knowing it could be set NULL by
	nfsd's vfs layer. This ends up crashing the kernel as described in
	bugzilla 193817.
	
	Fix the panic issue by getting inode pointer from dentry instead.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.12&r2=1.16.2.13

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2006-05-31 18:29:52

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	I missed header and local stack variable definition in previous check-in.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.11&r2=1.16.2.12

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2006-05-23 22:28:57

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	We miss c/mtime update in fsync() via previous check-in. This patch fixes
	that.
	
	We also forks gfs's fsync() and fdatasync() implementations in this patch.
	The fdatasync, where it flushes data but not meta data like the mtime or
	atime, will have the same performance as previous check-in. For fsync, we
	will flush everything as the old code did but it is still able to gain
	about 3x performance when compared with the original code due to the
	removal of repeated writepage().
	
	Data obtained from the test machine via fstest.c:
	
	Original code: both fsync and fdatasync:  240.94 KB/s
	This chech in: fdatasync:                 2.67   MB/s
	fsync:                     799.21 KB/s

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.10&r2=1.16.2.11

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2006-05-13 02:51:32

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Found a performance issue in gfs_fsync() implementation where GL_SYNC
	glock flag introduces repeated page writes and meta data flushes via
	customer benchmark. The upload patch:
	
	1. Replace the shared lock with an exclusive lock.
	2. Borrow linux VFS layer's generic_osync_inode() (used by O_SYNC code
	path) to flush the local in-core inode into the disk, instead of the
	original GFS inode_go_sync().
	
	After the changes, the (application) bandwidth jumps from 240.94 KB/s to
	2.67 MB/s, very close (and almost equal) to ext3's under lock_nolock mount
	option.
	
	For other details, check out bugzilla 190950.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.9&r2=1.16.2.10

cluster/gfs-kernel/src/gfs ops_file.c

[cfeist]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	cfeist@sourceware.org	2006-02-13 20:28:26

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Fixed locking to match 2.6.15 kernel (semaphore to mutex)

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.16.6.2.2.3&r2=1.16.6.2.2.4

cluster/gfs-kernel/src/gfs ops_file.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2006-01-05 17:18:33

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	break this _single_ line into three:
	
	if (gfs_is_stuffed(ip)) { error = gfs_unstuff_dinode(ip, gfs_unstuffer_sync, NULL); if (error)

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.8&r2=1.16.2.9

cluster/gfs-kernel/src/gfs ops_file.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	bmarzins@sourceware.org	2005-12-10 00:48:53

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Fix for bz 142849
	
	When you do gfs_write on a stuffed inode, you don't update the page cache,
	because the inodes are stored in the buffer cache. This doesn't effect reads,
	because gfs special cases the stuffed reads.  Unfortunately, sendfile needs to
	use the page cache, because it relys on the destination socket's sendpage
	routine to work. So my fix is: after you do a write on a stuffed inode, if the
	first page of the file is cached (It appears from looking at the code that
	there is already an assumption that stuffed inodes will never be more than a
	page in length) mark the cached page as not uptodate.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.16.6.2.2.2&r2=1.16.6.2.2.3

cluster/gfs-kernel/src/gfs ops_file.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	bmarzins@sourceware.org	2005-12-10 00:47:05

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Fix for bz 142849
	
	When you do gfs_write on a stuffed inode, you don't update the page cache,
	because the inodes are stored in the buffer cache. This doesn't effect reads,
	because gfs special cases the stuffed reads.  Unfortunately, sendfile needs to
	use the page cache, because it relys on the destination socket's sendpage
	routine to work. So my fix is: after you do a write on a stuffed inode, if the
	first page of the file is cached (It appears from looking at the code that
	there is already an assumption that stuffed inodes will never be more than a
	page in length) mark the cached page as not uptodate.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.5&r2=1.16.2.6

cluster/gfs-kernel/src/gfs ops_file.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Changes by:	bmarzins@sourceware.org	2005-12-10 00:44:12

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Fix for bz 142849
	
	When you do gfs_write on a stuffed inode, you don't update the page cache,
	because the inodes are stored in the buffer cache. This doesn't effect reads,
	because gfs special cases the stuffed reads.  Unfortunately, sendfile needs to
	use the page cache, because it relys on the destination socket's sendpage
	routine to work. So my fix is: after you do a write on a stuffed inode, if the
	first page of the file is cached (It appears from looking at the code that
	there is already an assumption that stuffed inodes will never be more than a
	page in length) mark the cached page as not uptodate.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&r1=1.20&r2=1.21

cluster/gfs-kernel/src/gfs ops_file.c

[bmarzins]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4U2
Changes by:	bmarzins@sourceware.org	2005-12-10 00:44:43

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Fix for bz 142849
	
	When you do gfs_write on a stuffed inode, you don't update the page cache,
	because the inodes are stored in the buffer cache. This doesn't effect reads,
	because gfs special cases the stuffed reads.  Unfortunately, sendfile needs to
	use the page cache, because it relys on the destination socket's sendpage
	routine to work. So my fix is: after you do a write on a stuffed inode, if the
	first page of the file is cached (It appears from looking at the code that
	there is already an assumption that stuffed inodes will never be more than a
	page in length) mark the cached page as not uptodate.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4U2&r1=1.16&r2=1.16.8.1

cluster/gfs-kernel/src/gfs ops_file.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	teigland@sourceware.org	2005-11-21 16:51:00

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	tidy code style

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.4&r2=1.16.2.5

cluster/gfs-kernel/src/gfs ops_file.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2005-11-21 16:49:07

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Check in Wendy Cheng's fix:
	Flush pages into storage in case of DirectIO falling back to BufferIO.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.16.6.2.2.1&r2=1.16.6.2.2.2

cluster/gfs-kernel/src/gfs ops_file.c

[teigland]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	STABLE
Changes by:	teigland@sourceware.org	2005-11-21 16:41:04

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Check in Kevin Anderson's mount sync patch:
	Without the patch, there is a large performance hit when using the -o sync
	mount option on gfs filesystems. The problem is that pages are not being
	flushed to disk when the gfs_writepage routine is invoked due to the
	transaction not yet being completed. Ref: bugzilla 173147.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=STABLE&r1=1.16.6.2&r2=1.16.6.2.2.1

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2005-11-17 20:21:44

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Check in Kevin Anderson's mount sync patch:
	
	Without the patch, there is a large performance hit when using the -o sync mount option on gfs filesystems. The problem is that pages are not being flushed to disk when the gfs_writepage routine is invoked due to the transaction not yet being completed. Ref: bugzilla 173147.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.3&r2=1.16.2.4

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2005-11-14 22:52:26

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	The i_sem should be re-locked right after gfs_glock_nq_m(). Otherwise, during error returns, the i_sem count will not be correct.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.2&r2=1.16.2.3

cluster/gfs-kernel/src/gfs ops_file.c

[wcheng]

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng@sourceware.org	2005-11-01 19:23:00

Modified files:
	gfs-kernel/src/gfs: ops_file.c 

Log message:
	Reorder exclusive glock and i_sem locking sequence to avoid read-write deadlock using direct IO on the same node (bugzilla 171488).

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_file.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.16.2.1&r2=1.16.2.2