From owner-cvs-all Thu Sep 24 17:59:26 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA24134 for cvs-all-outgoing; Thu, 24 Sep 1998 17:59:26 -0700 (PDT) (envelope-from owner-cvs-all) 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 RAA24105 for ; Thu, 24 Sep 1998 17:59:13 -0700 (PDT) (envelope-from dillon@backplane.com) Received: (dillon@localhost) by apollo.backplane.com (8.9.1/8.6.5) id RAA22443; Thu, 24 Sep 1998 17:59:06 -0700 (PDT) Date: Thu, 24 Sep 1998 17:59:06 -0700 (PDT) From: Matthew Dillon Message-Id: <199809250059.RAA22443@apollo.backplane.com> To: Luoqi Chen Cc: committers@FreeBSD.ORG Subject: Re: Kernel is hitting my debugging printf's References: <199809250052.UAA29657@lor.watermarkgroup.com> Sender: owner-cvs-all@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk :Bingo! That's it! I think this is the one that's responsible for the data loss. :After the page is put on the page cache queue, it could be reclaimed for :other use. The next time you write to the same disk block, the data has to be :reread from the disk which doesn't have latest modifications. : :To fix this problem, you either could change to if statements to check for :B_DELWRI bit, or clear B_RELBUF if B_DELWRI is set earlier in the function. :I prefer the latter because it doesn't make much sense carrying the B_RELBUF :bit around. : :-lq Ok, I will throw in clearing B_RELBUF if B_DELWRI is set just before the VMIO buffer rundown in brelse() and let it run for a day or two on our news box before comitting it. -Matt