From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 15:09:47 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3AAF1065686 for ; Mon, 29 Sep 2008 15:09:46 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by mx1.freebsd.org (Postfix) with ESMTP id 97D598FC0C for ; Mon, 29 Sep 2008 15:09:46 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by wr-out-0506.google.com with SMTP id c8so421828wra.27 for ; Mon, 29 Sep 2008 08:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=VpQgeLpcnM8yTtb6CI1cY0OZUjnqfJ4XXez2OhJniDo=; b=I8nhFD5Cc+FALb0r5Urp/CupFe2CJ5EYbY9VT7dzMACiJigbHtUhUg7oyy6TUKlRGs hsGu5RNFXyhe0dPKLwbeyb7oCx7NpkcutwcDdlaPWkT0N67lNFJHEXsLm6T1E8m4Wvw7 6j7itY9dOnnpn32/ZfOGdFJjgbNE0HTDuYGbU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=PRU+N+GJBIej5M2UZtKHCdyHnd5fueoLlZpR/dSW8igyBpT8X52TXF0C2WXW+nX+Dz Xi8Ir5Immbsi7rM9ciFoTkEM/NebIw65Rf1YeIxvRe4ZZqSxBewBhyuY4/V+S8JN4G0j OB8ophZcjVr3U2NmZJi9lZI1mXVc9sU8hi5nE= Received: by 10.151.47.7 with SMTP id z7mr8061912ybj.2.1222700985738; Mon, 29 Sep 2008 08:09:45 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Mon, 29 Sep 2008 08:09:45 -0700 (PDT) Message-ID: <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> Date: Mon, 29 Sep 2008 11:09:45 -0400 From: "Zaphod Beeblebrox" To: "Andrew Snow" In-Reply-To: <48E080C0.9070103@modulus.org> MIME-Version: 1.0 References: <20080921213426.GA13923@0lsen.net> <20080921220720.GA9847@icarus.home.lan> <249873145.20080926213341@takeda.tk> <20080927051413.GA42700@icarus.home.lan> <765067435.20080926223557@takeda.tk> <20080927064417.GA43638@icarus.home.lan> <588787159.20080927003750@takeda.tk> <5f67a8c40809282030l7888d942q548d570cd0b33be9@mail.gmail.com> <20080929040025.GA97332@icarus.home.lan> <48E080C0.9070103@modulus.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2008 15:09:47 -0000 On Mon, Sep 29, 2008 at 3:16 AM, Andrew Snow wrote: > However, as a core general purpose filesystem, it seems to have flaws, not >> the least of which is a re-separation of file cache and memory cache. >> > > For me, this doesn't matter because ZFS is so much faster than UFS > overall. Even if you don't use any of its features, the latest version > does sequential I/O and heavy random I/O faster than UFS on the same > hardware for me. > > Cases where UFS is faster are proving to be the exception rather than > the rule. > > However, I cannot recommend its use until it is stable, which it > currently still is not, under very heavy load. I certainly can't agree with this. I don't think you're measuring the performance of the machine --- only measuring the performance of the filesystem. When ZFS is active, memory is committed in the kernel to ZFS. That memory is then no longer available for paging. Also, there exists data within the ARC (I'm always tempted to say the ARC Cache, but that is redundant) that is also then in paging memory. You end up having to tune the size of the ARC to your workload, which is how UN*X did it upto 1992 or so. If you choose the wrong size for the ARC, you end up with very poor performance. In particular, the ARC fights for space with the nvidia binary driver (which really does need _real_ memory). To have the driver work at all, I have to keep the ARC from growing too large --- which is at odds with filesystem perofrmance.