From owner-freebsd-current@FreeBSD.ORG Thu Jul 8 21:30:36 2010 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 3E0EC106564A for ; Thu, 8 Jul 2010 21:30:36 +0000 (UTC) (envelope-from mm@FreeBSD.org) Received: from mail.vx.sk (core.vx.sk [188.40.32.143]) by mx1.freebsd.org (Postfix) with ESMTP id 649428FC1B for ; Thu, 8 Jul 2010 21:30:35 +0000 (UTC) Received: from core.vx.sk (localhost [127.0.0.1]) by mail.vx.sk (Postfix) with ESMTP id EFBABF5E9C; Thu, 8 Jul 2010 23:30:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.vx.sk Received: from mail.vx.sk ([127.0.0.1]) by core.vx.sk (mail.vx.sk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5Js6B7AvFjhl; Thu, 8 Jul 2010 23:30:31 +0200 (CEST) Received: from [10.9.8.1] (188-167-78-139.dynamic.chello.sk [188.167.78.139]) by mail.vx.sk (Postfix) with ESMTPSA id 80C41F5E92; Thu, 8 Jul 2010 23:30:31 +0200 (CEST) Message-ID: <4C364379.6020608@FreeBSD.org> Date: Thu, 08 Jul 2010 23:30:33 +0200 From: Martin Matuska User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sk; rv:1.8.1.23) Gecko/20090812 Lightning/0.9 Thunderbird/2.0.0.23 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Peter Jeremy References: <4C31C71C.2010606@FreeBSD.org> <20100708200446.GA33822@server.vk2pj.dyndns.org> In-Reply-To: <20100708200446.GA33822@server.vk2pj.dyndns.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1250 Content-Transfer-Encoding: 8bit Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT] ZFS v15 patch (version 3) 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, 08 Jul 2010 21:30:36 -0000 On 8. 7. 2010 22:04, Peter Jeremy wrote / napísal(a): > On 2010-Jul-05 13:50:52 +0200, Martin Matuska wrote: > >> As ZFS v15 is already being used in the Solaris 10 enterprise world, we >> can consider it well-tested. >> > So we know if the ZFS in Solaris 10 includes any fixes that aren't > publicly available? > > All fixes for ZFS in Solaris 10 are not publicly available and to customers only in binary form. But the list of fixed bug IDs is available and they match the OpenSolaris Bug IDs ;-) >> Direct link to the patch: >> http://people.freebsd.org/~mm/patches/zfs/v15/head-v15-v3.patch >> >> The patch applies cleanly against head and stable/8. >> > In order to apply it to a two-week-old stable/8, I needed to: > # mkdir cddl/contrib/opensolaris/lib/pyzfs > # mkdir cddl/contrib/opensolaris/lib/pyzfs/common > # mkdir cddl/contrib/opensolaris/cmd/pyzfs > > Other than verifying that it applies (with the above change), compiles > and runs, I haven't attempted any stress tests yet. > The -p0 flag creates all needed directories: patch -p0 < head-v15-v3.patch > Looking at the patchset, the most critical issue (IMHO) that doesn't > appear to have been addressed is the interaction between ZFS ARC and > the VM cache used by UFS/NFS: arc_memory_throttle() is still making > decisions solely on the amount of "free" memory, without considering > "inactive" or "cache". I am running a slight variant of a patch by > Artem Belevich (see http://pastebin.com/ZCkzkWcs) but he acknowledges > that patch is incomplete (and I've managed to wedge one of my systems > a couple of times whilst doing zfs send/recv). > > Without patching arc_memory_throttle(), a system behaves especially > poorly if it uses ZFS with any of mmap(2), UFS or NFS client - in my > case, ports/mail/mairix was almost guaranteed to wedge the system. > This is the problem that the following hack is intended to work around: > perl -e '$x = "x" x 1000000;' > > Regarding ARC, you might want to try the revision 209227 from head that is scheduled for MFC on 18.7.2010: http://people.freebsd.org/~mm/patches/zfs/head-12636.patch OpenSolaris onnv-revision: 12636:13b5d698941e OpenSolaris Bug IDs: 6950219 large ghost eviction causes high write latency http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6950219 6953403 arc_adjust might adjust MRU unnecessarily http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6953403 6951024 arc_adapt can lead to wild arc_p adjustment http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6951024