From owner-freebsd-current@FreeBSD.ORG Thu Dec 4 23:58:22 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 083011065670 for ; Thu, 4 Dec 2008 23:58:22 +0000 (UTC) (envelope-from thomas@bsdunix.ch) Received: from conversation.bsdunix.ch (ns1.bsdunix.ch [82.220.1.90]) by mx1.freebsd.org (Postfix) with ESMTP id B4A6B8FC0C for ; Thu, 4 Dec 2008 23:58:21 +0000 (UTC) (envelope-from thomas@bsdunix.ch) Received: from localhost (localhost [127.0.0.1]) by conversation.bsdunix.ch (Postfix) with ESMTP id F35BA5D61; Fri, 5 Dec 2008 00:40:34 +0100 (CET) X-Virus-Scanned: by amavisd-new at mail.bsdunix.ch Received: from conversation.bsdunix.ch ([127.0.0.1]) by localhost (conversation.bsdunix.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PUHwT+OtF3YD; Fri, 5 Dec 2008 00:40:31 +0100 (CET) Received: from Toms-Kraftbuch.local (home.bsdunix.ch [82.220.17.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by conversation.bsdunix.ch (Postfix) with ESMTP id 4DB9C5D33; Fri, 5 Dec 2008 00:40:31 +0100 (CET) Message-ID: <49386A6E.50500@bsdunix.ch> Date: Fri, 05 Dec 2008 00:40:30 +0100 From: Thomas Vogt User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: Wes Morgan References: <20081117205526.GC1733@garage.freebsd.pl> <20081202203308.GA13818@hyperion.scode.org> <200812021254.21242.fjwcash@gmail.com> <20081202232924.GA19134@hyperion.scode.org> <31C70CBC-488A-4A9A-A642-37855E8F1DD1@lassitu.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 05 Dec 2008 00:25:56 +0000 Cc: FreeBSD Current , Stefan Bethke , Thomas Vogt Subject: Re: HEADS UP: New ZFS in the tree. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Dec 2008 23:58:22 -0000 Wes Morgan schrieb: > On Thu, 4 Dec 2008, Thomas Vogt wrote: > >> Hello Stefan >> >> Am 04.12.2008 um 00:33 schrieb Stefan Bethke: >>> Am 03.12.2008 um 00:29 schrieb Peter Schuller: >>> >>>>> I've noticed the past couple of days, when using the server (not very >>>>> often), every now and then, the GUI (KDE 4.1) will "hang" for up to 5 >>>>> minutes (no mouse movement, no keyboard events), while the drives >>>>> work like >>>>> crazy. >>>> >>>> I was not explicit about it, but FWIW in my case the hang is not due >>>> to drive saturation. The drives were mostly idle (except some stuff >>>> triggered by a buildworld I had going) during the extended period of >>>> ktorrent being unkillable. But again I never had this happen >>>> pre-CURRENT. >>> >>> Just a very brief "me too" (but possibly different effect): I'm >>> stress testing two machines I put together over the weekend with an >>> endless loop of make -j4 universe, with /usr/obj on ZFS, with a >>> single disk. One of the two machines has now been stuck for a couple >>> of hours, and trying to access /tank results in a hung process, as >>> will zfs list. >>> >>> I'll reboot and see what happens, and if I can trigger it again, >>> willt try to produce more details. >>> >>> I have set >>> vfs.zfs.arc_max="512M" >>> vfs.zfs.prefetch_disable=1 >>> in loader.conf >>> >>> FreeBSD lokschuppen.lassitu.de 8.0-CURRENT FreeBSD 8.0-CURRENT #1: >>> Wed Dec 3 07:05:03 UTC 2008 >>> root@lokschuppen.lassitu.de:/usr/obj/usr/src/sys/EISENBOOT amd64 >> >> Try to disable ZIL in loader.conf: >> vfs.zfs.zil_disable="1" >> >> It helped me to stop deadlocks during rsync processes. As long as you >> don't run any databases or any fsync() intensiv applications, i don't >> see any drawbacks in disabling zil. The drawbacks are for the >> applications itself not for ZFS. ZFS will be always consistent on disk >> due to its transaction model even without ZIL. > > Are you sure about that? Without the ZIL, wouldn't you need to scrub > each pool after every crash, much as fsck with UFS? AFAIK no. http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Disabling_the_ZIL_.28Don.27t.29 The ZFS pool integrity itself is not compromised by this tuning. There are many blog entries from ZFS developer with the same conclusion. Regards, Thomas