From owner-freebsd-hackers Thu Apr 19 12:33:23 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 00C5537B443; Thu, 19 Apr 2001 12:33:14 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.11.2) id f3JJXDG58095; Thu, 19 Apr 2001 12:33:13 -0700 (PDT) (envelope-from dillon) Date: Thu, 19 Apr 2001 12:33:13 -0700 (PDT) From: Matt Dillon Message-Id: <200104191933.f3JJXDG58095@earth.backplane.com> To: John Baldwin Cc: Mike Bristow , hackers@FreeBSD.ORG, Jeremiah Gowdy Subject: Re: OpenBSD's FFS/dirpref/softupdates improvements References: Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG I've accepted the job of MFCing the dirpref stuff to -stable ... after the 4.3 release. If fsck is clobbering consistently we can probably make the kernel avoid a panic. I'll look at the issue carefully when I do the MFC. -Matt :On 19-Apr-01 Mike Bristow wrote: :> On Thu, Apr 19, 2001 at 08:57:37AM -0700, Jeremiah Gowdy wrote: :>> "Two aspects of the FFS filesystem in OpenBSD have received significant :>> improvements since 2.8, increasing performance dramatically. Thanks to art, :>> gluk, csapuntz, and a host of other developers and testers, Soft Updates are :>> now much more stable than ever before. The second improvement, contributed :>> by gluk@openbsd.org, is a new directory allocation policy (codenamed :>> "dirpref"). Coupled with soft updates, the new dirpref code offers up to a :>> 60x speed increase in gluk's tests, documented here:" :>> :>> http://groups.google.com/groups?q=dirpref&num=100&hl=en&lr=&safe=off&rnum=2& :>> seld=905073910&ic=1 :>> :>> Does anyone know anything about this ? :> :> Commited to -current about 10 April. :> :> I suspect that Jordan would shoot someone who suggested a MFC before :> 4.3 is out. : :It needs more work, too. If you try to use an old fsck with the new kernel, :then the old fsck will clobber some new variables in the superblock. Then the :new kernel will panic later on instead of doing a sanity check on the new :values in the superblock and falling back to defaults if they are bogus. This :is a major POLA bug and the changes shouldn't go into 4.x unless this is fixed. :This breaks the recommended method of updating stable by doing the installworld :after rebooting into a new kernel. : :-- : :John Baldwin -- http://www.FreeBSD.org/~jhb/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message