From owner-freebsd-stable@FreeBSD.ORG Sat Feb 9 14:24:41 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E472108 for ; Sat, 9 Feb 2013 14:24:41 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.38]) by mx1.freebsd.org (Postfix) with ESMTP id 23667CF9 for ; Sat, 9 Feb 2013 14:24:40 +0000 (UTC) Received: from [78.35.140.200] (helo=fabiankeil.de) by smtprelay04.ispgateway.de with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1U4BL0-0002lA-5A; Sat, 09 Feb 2013 15:23:30 +0100 Date: Sat, 9 Feb 2013 15:19:18 +0100 From: Fabian Keil To: Jeremy Chadwick Subject: Re: patch which implements ZFS LZ4 compression Message-ID: <20130209151918.221176cd@fabiankeil.de> In-Reply-To: <20130208230830.GA45081@icarus.home.lan> References: <511581C9.5040608@delphij.net> <20130208230830.GA45081@icarus.home.lan> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/0wf6BJH=Iy9Q=Ew31ac7O62"; protocol="application/pgp-signature" X-Df-Sender: Nzc1MDY3 Cc: freebsd-stable@freebsd.org, d@delphij.net, Dan Langille X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Feb 2013 14:24:41 -0000 --Sig_/0wf6BJH=Iy9Q=Ew31ac7O62 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Jeremy Chadwick wrote: > On Fri, Feb 08, 2013 at 02:52:57PM -0800, Xin Li wrote: > > On 02/08/13 14:29, Dan Langille wrote: > > > Here is a patch against FreeBSD 9.1 STABLE which implements ZFS LZ4 > > > compression. > > >=20 > > > https://plus.google.com/106386350930626759085/posts/PLbkNfndPiM > > >=20 > > > short link: http://bpaste.net/show/76095 > >=20 > > Please DO NOT use this patch! It will ruin your data silently. > >=20 > > As I already posted on Ivan's Google+ post, I'm doing final universe > > builds to make sure that there is no regression and will merge my > > changes to -HEAD later today. >=20 > Another compression algorithm, this time 50%+ faster than lzjb. Great, > fine, wonderful, awesome, kudos, huzzah, blah blah blah. >=20 > So when is someone going to step up to the plate and fix how compression > (as well as dedup) destroys interactivity on FreeBSD? Do I need to > remind folks of this issue once again? Here you have it, dated October > 2011, including the root cause and how it was fixed in Solaris et al: >=20 > Description: >=20 > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html >=20 > Explanation and how Solaris et al fixed it, and how on Solaris the > problem was major enough that it even caused NFS timeouts (sound > familiar to anyone?): >=20 > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html >=20 > Further testing showing gzip-1 vs. lzjb and interactivity stalls: >=20 > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html >=20 > This is still a problem with base/stable/9. And as I have said > elsewhere on lists, do not ask me to run CURRENT -- it will be a cold > day in hell before I ever do that. I assume this same problem exists in > CURRENT unless I have some key developer/committer say "I backported > this fix in CURRENT, absolutely 100% sure". >=20 > I'm also wondering why iXSystems hasn't stepped up to the plate to > contribute to making this happen, given their business focus. I do not > have the knowledge of the kernel (or of threading) to fix this myself, > and for that I do apologise. >=20 > But every time I see compression or dedup mentioned, I use the > opportunity to bring up this subject. STOP ADDING FEATURES AND FIX > STUFF LIKE THIS INSTEAD -- while new algorithms are neat/fun toys, they > do not truly fix issues like this. How this problem has continually > gotten overlooked is beyond me. Did you consider that other people may have different priorities than you do? > If you want a PR for it, I'll file one, but all it's going to contain is > the contents of this Email. My impression is that your emails describe symptoms and contain some speculation about what the cause might be. I didn't see any sched traces, so it's unclear (to me) that priorities are actual the problem. It's also unclear to me why the dedup and compression issues should be related. There are lots of dedup performance issues reported for Solaris as well and I doubt that they can be fixed for FreeBSD without significantly deviating from the ZFS upstream. I'm not saying a PR would be useless, but in my experience PRs with insufficient information just stay open and if the problem isn't important enough for you to provide additional information filing a PR is unlikely to have a great impact: http://www.freebsd.org/cgi/query-pr-summary.cgi?category=3D&text=3Dzfs Fabian --Sig_/0wf6BJH=Iy9Q=Ew31ac7O62 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEWWuoACgkQBYqIVf93VJ2/1wCfYDJA25qIwfK0sIGAoa64pNEh WW4Ani7iAFn6BtDgiu2xNGr51/qsRDU9 =YXec -----END PGP SIGNATURE----- --Sig_/0wf6BJH=Iy9Q=Ew31ac7O62--