Date: Mon, 11 Feb 2013 11:37:38 +0100 From: Oliver Brandmueller <ob@e-Gitt.NET> To: freebsd-stable@freebsd.org Subject: Re: patch which implements ZFS LZ4 compression Message-ID: <20130211103737.GS38901@e-Gitt.NET> In-Reply-To: <20130209204436.GA67890@icarus.home.lan> References: <C1BC7885-9C79-4534-8047-7408ED46A78A@langille.org> <511581C9.5040608@delphij.net> <20130208230830.GA45081@icarus.home.lan> <20130209151918.221176cd@fabiankeil.de> <20130209204436.GA67890@icarus.home.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Sat, Feb 09, 2013 at 12:44:36PM -0800, Jeremy Chadwick wrote: > Bottom line: people enable compression on an fs, issue large amounts of > write I/O to that fs (say hundreds of megabytes, or gigabytes), and > start to see the entire system intermittently stalling hard (for > multiple seconds at a time). This affects everything from switching VTs > on physical console to packets going across SSH. The stalls vary in > duration depending on what compression type is used (lzjb vs. gzip-1 -- > I cannot even imagine what gzip-9 would be like). I described it as > verbosely as I could, including going back and "re-testing" because > people felt the "ZFSv28 import might have addressed it" (it did not): > > http://lists.freebsd.org/pipermail/freebsd-fs/2011-October/012752.html > > The exact same behaviour happens if dedup is used. There is no relation > between compression (the feature) and dedup (the feature), obviously, > but the symptom I've described matches Bob's explanation perfectly. > > If you want to provide the aforementioned instructions, I'll happily > follow them. Did you try using 4BSD instead of ULE at some point? I had similar problems and that completely fixed it for me. Which would mean, that there's some interactio between scheduler and ZFS code. - Oliver -- | Oliver Brandmueller http://sysadm.in/ ob@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130211103737.GS38901>