Date: Tue, 24 Nov 1998 16:41:40 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: "David G. Andersen" <danderse@cs.utah.edu> Cc: hackers@FreeBSD.ORG, vanmaren@cs.utah.edu, sclawson@cs.utah.edu Subject: Re: MFS hang when copying large file to it (vm problem?) Message-ID: <199811250041.QAA26569@apollo.backplane.com> References: <13915.12507.346867.242762@torrey.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
:(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.
<dillon@backplane.com> (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 <sys/sysproto.h> /* for msync_args */
> #include <sys/mman.h> /* 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811250041.QAA26569>