Date: Fri, 8 Feb 2013 15:08:30 -0800 From: Jeremy Chadwick <jdc@koitsu.org> To: d@delphij.net Cc: freebsd-stable@freebsd.org, Dan Langille <dan@langille.org> Subject: Re: patch which implements ZFS LZ4 compression Message-ID: <20130208230830.GA45081@icarus.home.lan> In-Reply-To: <511581C9.5040608@delphij.net> References: <C1BC7885-9C79-4534-8047-7408ED46A78A@langille.org> <511581C9.5040608@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > > > https://plus.google.com/106386350930626759085/posts/PLbkNfndPiM > > > > short link: http://bpaste.net/show/76095 > > Please DO NOT use this patch! It will ruin your data silently. > > 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. Another compression algorithm, this time 50%+ faster than lzjb. Great, fine, wonderful, awesome, kudos, huzzah, blah blah blah. 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: Description: http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012718.html 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?): http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012726.html Further testing showing gzip-1 vs. lzjb and interactivity stalls: http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html 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". 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. 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. If you want a PR for it, I'll file one, but all it's going to contain is the contents of this Email. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130208230830.GA45081>