Date: Wed, 19 Nov 2014 13:08:25 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Steven Hartland <killing@multiplay.co.uk>, freebsd-fs@FreeBSD.org Subject: Re: No more free space after upgrading to 10.1 and zpool upgrade Message-ID: <546C7A29.9020103@FreeBSD.org> In-Reply-To: <546C18F4.1090209@multiplay.co.uk> References: <CA%2Bq%2BTcqo2CL%2B00-4RTD1=WStOSYtawwsZbC1tpZ1G9CbiBp_Dw@mail.gmail.com> <20141116080128.GA20042@exhan.dylanleigh.net> <CA%2Bq%2BTcoC4gTPqGc_V3xv%2BcWxJuB2r8YioH_NLfaj=5xwsaXW0w@mail.gmail.com> <20141118054443.GA40514@core.summit> <546B8203.5040607@platinum.linux.pl> <546B9754.4060906@delphij.net> <20141119013611.GA52102@core.summit> <546C01C5.7080605@delphij.net> <546C18F4.1090209@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19/11/2014 06:13, Steven Hartland wrote: > The new space map code should help with that and a fixed 3.125% is a large > portion of a decent sized pool. > > On our event cache box for example thats 256GB which feels like silly amount to > reserve. > > Does anyone have any stats which backup the need for this amount of free space > on large pool arrays, specifically with spacemaps enabled? There was a presentation about the spacemap code at the OpenZFS Devsummit. One point is that going above 95% will kill performance (actually sooner). This is applicable to all spacemap algorithms currently available. There is a pretty graph at page 13 here http://open-zfs.org/w/images/3/31/Performance-George_Wilson.pdf -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?546C7A29.9020103>