From owner-freebsd-hackers Fri Feb 26 16:19:29 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 70A9A15027 for ; Fri, 26 Feb 1999 16:19:27 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA20214; Fri, 26 Feb 1999 16:19:11 -0800 (PST) (envelope-from dillon) Date: Fri, 26 Feb 1999 16:19:11 -0800 (PST) From: Matthew Dillon Message-Id: <199902270019.QAA20214@apollo.backplane.com> To: Matthew Jacob , freebsd-hackers@FreeBSD.ORG Subject: Re: Panic in FFS/4.0 as of yesterday - update References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :: Pop the patch at 1:00 p.m. today. By then I should have an update. :: The one I have now is very close - just a couple of missing wakeups. : : This patch seems to fix buildworld. I ran Matt Jacob's STEST and managed : to lock it up -- looks like flushdirtybuffers() needs to allow the syncer : to get in whether or not some other process is flushing dirty buffers : at the same time. : : I'll have another update to vfs_bio on my site at around 4:00 p.m. : -Matt Ugh. inode lock now - if a process has a lock on an inode and then blocks in getnewbuf(), the syncer can still allocate buffers but can deadlock trying to lock the inode. I'll bet the inode lockup reported a few days ago under heavy test loads is due to this problem too. I think the solution may be to have the syncer reschedule a vnode which it finds locked rather then block getting the lock as it does now. ( excerpt from kern/vfs_subr.c, sched_sync() ) splx(s); while ((vp = LIST_FIRST(slp)) != NULL) { vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p); (void) VOP_FSYNC(vp, p->p_ucred, MNT_LAZY, p); VOP_UNLOCK(vp, 0, p); s = splbio(); if (LIST_FIRST(slp) == vp) { ... -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message