From owner-freebsd-arch Mon Mar 3 21:42:58 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65F1E37B401 for ; Mon, 3 Mar 2003 21:42:57 -0800 (PST) Received: from bricore.com (adsl-64-168-71-68.dsl.snfc21.pacbell.net [64.168.71.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9F26943F3F for ; Mon, 3 Mar 2003 21:42:56 -0800 (PST) (envelope-from lchen@briontech.com) Received: from luoqi (luoqi.bricore.com [192.168.1.63]) by bricore.com (8.12.6/8.12.6) with SMTP id h245gY3r011472; Mon, 3 Mar 2003 21:42:52 -0800 (PST) (envelope-from lchen@briontech.com) From: "Luoqi Chen" To: "Jeff Roberson" , Subject: RE: vtruncbuf() Date: Mon, 3 Mar 2003 21:46:39 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <20030303151503.N72102-100000@mail.chesapeake.net> X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > vtruncbuf() does a few things that I'm not terribly certain I understand. > I'm hoping someone can elaborate on this. > > Once we have eliminated all bufs that are above the truncation mark we do > a sort of inline sync of all indirect blocks. Why do we have to do this > sync? Is this required? If so, why don't we just fsync here? Or > require the > filesystem to do it. There are a few things that bother me about the > current code there. > I think the idea was to avoid calling fsync. > Firstly, it makes assumptions about negative blknos. So this scheme > doesn't work for filesystems that don't use this method for indexing > their metadata. The code is a little ufs specific, but should still work for other FS -- it doesn't hurt to write out dirty bufs. > Secondly, it doesn't hold a lock while inspecting > B_DELWRI. > It's intentional, see below... > There is also a really weird check to see if the buf's vp matches the vp > we're truncating. This doesn't really make sense since we just > pulled this > buf off of the dirty block lists for this vnode. > ..., the buf is not locked, remember :) > Comments please? > > Thanks, > Jeff > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message