xfs
[Top] [All Lists]

[Bug 198] file corruption over NFSv3 UDP using 1.2pre3

To: xfs-master@xxxxxxxxxxx
Subject: [Bug 198] file corruption over NFSv3 UDP using 1.2pre3
From: bugzilla-daemon@xxxxxxxxxxx
Date: Tue, 3 Dec 2002 11:36:27 -0800
Sender: linux-xfs-bounce@xxxxxxxxxxx
http://oss.sgi.com/bugzilla/show_bug.cgi?id=198





------- Additional Comments From cattelan@xxxxxxxxxxx  2002-12-03 11:36 -------
Additional comments from Stephane

I do have one bit of positive progress to report (finally)! I commented out the
purging of the XFS refcache and got no corruption (ran about 56 hours).

As you know, the refcache is just a table of open files kept by XFS,
specifically to speedup nfsd. Otherwise, whenever a file is closed XFS does a
truncate (and perhaps other stuff, probably to clear out any over 
allocation...)  
and the truncate takes a bit of time as it goes through all the file's pages. So
by keeping them open, this penalty is avoided. To make sure that file info gets
flushed, entries are purged regularly from the refcache: in short our files get
closed every
30seconds. Well I just commented that part out. That's a test of course, not a
solution.

--- linux/fs/xfs/xfs_vfsops.c.orig      Sat Nov 30 01:09:15 2002
+++ linux/fs/xfs/xfs_vfsops.c   Sat Nov 30 01:09:43 2002
@@ -1515,7 +1515,7 @@
         * eventually kicked out of the cache.
         */
        if (flags & SYNC_BDFLUSH) {
-               xfs_refcache_purge_some(mp);
+               //xfs_refcache_purge_some(mp);
        }
 
        /*

I'll look at the code this morning and try to understand what's going on.  My
guess is that the file is being closed (truncated and perhaps other stuff) and
at the same time some other request is extending it, and this confuses XFS
somehow, perhaps some locking is missing. It's still surprising that data jumps
from one file to another though.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


<Prev in Thread] Current Thread [Next in Thread>