From owner-freebsd-hackers Tue Nov 24 16:41:50 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA02367 for freebsd-hackers-outgoing; Tue, 24 Nov 1998 16:41:50 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA02360 for ; Tue, 24 Nov 1998 16:41:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id QAA26569; Tue, 24 Nov 1998 16:41:40 -0800 (PST) (envelope-from dillon) Date: Tue, 24 Nov 1998 16:41:40 -0800 (PST) From: Matthew Dillon Message-Id: <199811250041.QAA26569@apollo.backplane.com> To: "David G. Andersen" Cc: hackers@FreeBSD.ORG, vanmaren@cs.utah.edu, sclawson@cs.utah.edu Subject: Re: MFS hang when copying large file to it (vm problem?) References: <13915.12507.346867.242762@torrey.cs.utah.edu> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :(Search for "VM AND messed" in -hackers to get the full thread) : :where Don Lewis stated: : : Do you think this could explaint the MFS related hangs I've been seeing : in 2.1-stable? If I use MFS for /tmp, copy a large file into /tmp, : delete the file, then copy it into /tmp again, the machine will hang. : It responds to pings. It will also respond to ^T until I try to : interrupt a process with ^C. The only way to unhang it is to use : the reset button. : :It's fairly trivial to reproduce, but we're running SMP with our :typical heavily networked environment. Has anyone encountered this, :have a fix for it, or care to try to reproduce it on a less :complicated machine, before I submit a PR and/or dig more deeply into :it? : :Thanks in advance, Check the RSS of the MFS process handling /tmp. You will probably find that it grows and never gets swapped out. I have included one of my patches below. This is an old patch, so you will have to mess with it manually, but it should help with your problem if you can figure out where all the mods go. I never did get this patch into the CVS tree, oh well. -Matt : -Dave : :-- :work: danderse@cs.utah.edu me: angio@pobox.com : University of Utah http://www.angio.net/ : Department of Computer Science : :To Unsubscribe: send mail to majordomo@FreeBSD.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet Communications & God knows what else. (Please include original email in any response) Index: mfs_vfsops.c =================================================================== RCS file: /src/FreeBSD-CVS/ncvs/src/sys/ufs/mfs/mfs_vfsops.c,v retrieving revision 1.41 diff -r1.41 mfs_vfsops.c 48a49,50 > #include /* for msync_args */ > #include /* for msync_args */ 432a435,441 > /* > * must mark the calling process as a system process > * so the pager doesn't try to kill it. Doh! And the > * pager may because the resident set size may be huge. > */ > p->p_flag |= P_SYSTEM; > 471c480,481 < * EINTR/ERESTART. --- > * EINTR/ERESTART. It will return EWOULDBLOCK if the timer > * expired. 482,483c492,495 < } < else if (tsleep((caddr_t)vp, mfs_pri, "mfsidl", 0)) --- > } else { > int r = tsleep((caddr_t)vp, mfs_pri, "mfsidl", hz * 10); > > if (r && r != EWOULDBLOCK) 484a497,522 > } > > /* > * we should call msync on the backing store every 30 seconds, > * otherwise the pages are not associated with the file and guess > * what! the syncer never sees them. msync has no effect > * if the backing store is swap, but a big effect if it's a file > * (e.g. an NFS mounted file). > */ > { > static long lsec; > int dt = time_second - lsec; > > if (dt < -30 || dt > 30) { > struct msync_args uap; > > lsec = time_second; > > uap.addr = mfsp->mfs_baseoff; > uap.len = mfsp->mfs_size; > uap.flags = MS_ASYNC; > > msync(curproc, &uap); > } > } > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message