From owner-freebsd-stable@FreeBSD.ORG Mon Sep 29 15:49:07 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 4BC261065687 for ; Mon, 29 Sep 2008 15:49:07 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by mx1.freebsd.org (Postfix) with ESMTP id F24B98FC0A for ; Mon, 29 Sep 2008 15:49:06 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by yw-out-2324.google.com with SMTP id 9so332986ywe.13 for ; Mon, 29 Sep 2008 08:49:06 -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=dfV7c6oJkTI/mXmSDw5pGH7+GP0pSiICh/tsKmcmmuE=; b=sjeAuslrzM3CZ9aY40h63K+hKv9PSzOexFq/8NoXxmBRd2CqlvwSM45vVhLFpawL2+ 3+qHTXT9MUtBQgToX/mvNp1U4dXFsOfWB9koxcpV2kyvZWHbvYl5FmtmkYHReqrikVhc 3KKAG6TdFHdJcI+0buDEA/N8yIemHtMmwFgPo= 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=kh+CXkgBW7iDEzRu0x8kqLDpaTffG2hmooHIT9pCHhhGvtLiyQoiR5eIlLaYuThCYZ 4scPtgIBDGf3PwdmnE1KBj5ewiTLQisYxLT6CicVNevi4jPrv1+qfqGnOBmnlgp0KUjJ BNfiRptCYjJApS9JY8oK/7ATO+jLYOiO7wOXs= Received: by 10.151.45.2 with SMTP id x2mr8073024ybj.114.1222703346231; Mon, 29 Sep 2008 08:49:06 -0700 (PDT) Received: by 10.150.137.11 with HTTP; Mon, 29 Sep 2008 08:49:06 -0700 (PDT) Message-ID: <5f67a8c40809290849m413eebe6sd31a493aea506932@mail.gmail.com> Date: Mon, 29 Sep 2008 11:49:06 -0400 From: "Zaphod Beeblebrox" To: "Andrew Snow" In-Reply-To: <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> MIME-Version: 1.0 References: <20080921213426.GA13923@0lsen.net> <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> <5f67a8c40809290809j58639df8ka65184151161cab6@mail.gmail.com> 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:49:07 -0000 On Mon, Sep 29, 2008 at 11:09 AM, Zaphod Beeblebrox wrote: > > 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. > I thought about this statement a bit, and I believe it might be good to give a real world example. I use spamprobe. It's a dual-word basian spam filter. It runs from procmail as part of the local delivery process on my laptop for mail. It uses one of the berkley DB variants (I forget which at the moment and my binary is statically linked so it will run on AMD64 as well as I386, so I can't easily check). I strongly suspect that the basic operation of spamprobe involves mmap()ing the file (80 to 100 meg), performing a flurry of lookups (words in the message) followed by a flurry of updates, followed by closing the file. Now my current laptop has ZFS for my home directories and that ZFS is backed by two 320G laptop drives (RAID 1). My old laptop has UFS on a single 160G laptop drive. The old laptop would deliver 10 to 20 email messages per second through spamprobe. The new laptop deilvers a mail message every 2 to 5 seconds. In the UFS case, there would be little disk activity. Running spamprobe would only involved cached items and the disk activity would be the occaisional write to sync the new data and writes to deposit each email message. Now there's some things I don't know. Is the whole file rewritten to sync the changes? It seems like it is. Whatever the difference between UFS and ZFS here, it's triggering some pathological behavior. The needs of NAS are not the needs of a local filesystem. They are different beasts. If ZFS is optimized for being a NAS store, it does this well. Maybe UFS can become more ZFS like or vice-versa. ZFS is a comparatively young filesystem (and UFS is an equally old one).