From owner-freebsd-current Wed Mar 4 18:31:31 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA29711 for freebsd-current-outgoing; Wed, 4 Mar 1998 18:31:31 -0800 (PST) (envelope-from owner-freebsd-current@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 SAA29704 for ; Wed, 4 Mar 1998 18:31:29 -0800 (PST) (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 CAA20857 for ; Thu, 5 Mar 1998 02:30:49 GMT Date: Thu, 5 Mar 1998 11:30:49 +0900 (JST) From: Michael Hancock To: current@FreeBSD.ORG Subject: SoftUpdates! Re: Donations. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I want to see Kirk McKusick's softupdates go into the tree soon. This is a very significant step in the development of FreeBSD. We will get higher performance ffs without integrity compromises. http://www.ece.cmu.edu/~ganger/papers/CSE-TR-254-95/ I think these changes in themselves warrant a 3.0 jump. Giant lock or subsystem coarse lock SMP and softupdates is probably a good target. When softupdates are are applied and have stabilized a bit, I'll submit the first set of VFS_VRELE patches for vop_create, vop_mknod, and vop_symlink. This is mostly just grunt work but is a fundamental first step in making the stacking layers work. It will clean up ugly hacks like WILLRELE and make some things a lot easier to get working for file systems like devfs. It will also prevent VT_TFS-like hacks that third parties must sometime resort to forcing on us because we didn't have a proper VFS interface to allow them to manage their own vnodes. Mike Hancock To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message