From owner-freebsd-hackers Sat Feb 27 11: 1:51 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 2633B1513C for ; Sat, 27 Feb 1999 11:01:26 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA28577; Sat, 27 Feb 1999 11:01:10 -0800 (PST) (envelope-from dillon) Date: Sat, 27 Feb 1999 11:01:10 -0800 (PST) From: Matthew Dillon Message-Id: <199902271901.LAA28577@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 : 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. I'm still working on it. I found out why softupdates was creating such a mess -- it disables the flushing of dirty buffers in bdwrite(), which can easily cause a low memory deadlock. I managed to get through 25 iterations of STEST, then NFS got into an endless loop. I'm tracking that down now. I've also determined that flushdirtybuffers() has aweful performance compared to the syncer. It's so bad that if you ever hit it, the disk goes nuts. It may be a few more days before I can get a working patch. I need to get feedback from Kirk re: the softupdates problem. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message