From owner-freebsd-fs Thu Apr 16 22:24:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id WAA22174 for freebsd-fs-outgoing; Thu, 16 Apr 1998 22:24:37 -0700 (PDT) (envelope-from owner-freebsd-fs@FreeBSD.ORG) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA22156; Fri, 17 Apr 1998 05:24:28 GMT (envelope-from michaelh@cet.co.jp) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.8/CET-v2.2) with SMTP id FAA17520; Fri, 17 Apr 1998 05:23:40 GMT Date: Fri, 17 Apr 1998 14:23:40 +0900 (JST) From: Michael Hancock To: freebsd-current@FreeBSD.ORG cc: freebsd-fs@FreeBSD.ORG Subject: Re: Updated vfs patches In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 17 Apr 1998, Michael Hancock wrote: > http://www.freebsd.org/~mch/vop1a.diff > > 1) In the original code, ext2_rmdir and msdosfs_rmdir release the lock > across the truncate call but ufs_rmdir doesn't. The ufs_rmdir > implementation make it clean for me because I just delete the vput(), but > in ext2_rmdir and msdosfs_rmdir I must reacquire the lock so the generic > layer can do the vput() (phew!). I'm not sure if we should be holding a > lock across truncate and I have yet to review the logs yet to see why. > Perhaps someone can shed some light on this. I found it (POST_SOFTUPDATES)! Do we not block when calling truncate with softupdates on? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message