Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 9 Jul 2010 06:04:47 +1000
From:      Peter Jeremy <peterjeremy@acm.org>
To:        Martin Matuska <mm@FreeBSD.org>
Cc:        freebsd-current@FreeBSD.org
Subject:   Re: [CFT] ZFS v15 patch (version 3)
Message-ID:  <20100708200446.GA33822@server.vk2pj.dyndns.org>
In-Reply-To: <4C31C71C.2010606@FreeBSD.org>
References:  <4C31C71C.2010606@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2010-Jul-05 13:50:52 +0200, Martin Matuska <mm@FreeBSD.org> 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?

>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.

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 =3D "x" x 1000000;'

--=20
Peter Jeremy

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (FreeBSD)

iEYEARECAAYFAkw2L14ACgkQ/opHv/APuIfyEwCeMjTRbKEwLIUW9rI4X5JGyal2
BQYAmQH09CPzkKgF+1hv/JBHCAdYqZU1
=0PaB
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100708200446.GA33822>