From owner-freebsd-fs@FreeBSD.ORG Wed Nov 19 02:34:45 2014 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD40B4AC for ; Wed, 19 Nov 2014 02:34:45 +0000 (UTC) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC7A298F for ; Wed, 19 Nov 2014 02:34:45 +0000 (UTC) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 657B822D99; Tue, 18 Nov 2014 18:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1416364485; x=1416378885; bh=+W7SmbTaYoOcWF+PDHNWQGFlPbT6ocVXxQy8RWv/2hM=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=yjjyYOf2qJfUdTPzndjFT1NQYcBQ/JlPgpHkg6O58Bgay5B+pRYygJxwggR8dSO63 P7d7wldIi5Y1S3g7S3GsEYM2jOCtejrrCjj6jS1J8QunDdjYJlkD/gcLrDg6nr1LSA SApQPs6QuDzFoFXjZ89J2qhf+OZJdg1jnPcw14uE= Message-ID: <546C01C5.7080605@delphij.net> Date: Tue, 18 Nov 2014 18:34:45 -0800 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Emil Mikulic , d@delphij.net Subject: Re: No more free space after upgrading to 10.1 and zpool upgrade References: <20141116080128.GA20042@exhan.dylanleigh.net> <20141118054443.GA40514@core.summit> <546B8203.5040607@platinum.linux.pl> <546B9754.4060906@delphij.net> <20141119013611.GA52102@core.summit> In-Reply-To: <20141119013611.GA52102@core.summit> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-fs@freebsd.org X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 02:34:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 11/18/14 17:36, Emil Mikulic wrote: > On Tue, Nov 18, 2014 at 11:00:36AM -0800, Xin Li wrote: >> On 11/18/14 09:29, Adam Nowacki wrote: >>> This commit is to blame: >>> http://svnweb.freebsd.org/base?view=revision&revision=268455 >>> >>> 3.125% of disk space is reserved. > > This is the sort of thing I suspected, but I didn't spot this > commit. > >> Note that the reserved space is so that one can always delete >> files, etc. to get the pool back to a usable state. > > What about the "truncate -s0" trick? That doesn't work reliably? > >> I've added a new tunable/sysctl in r274674, but note that tuning >> is not recommended > > Thanks!! > > Can you give us an example of how (and when) to tune the sysctl? sysctl vfs.zfs.spa_slop_shift=6 would tune down the reserved space to 1/(2^6) (=1.5625%). Personally I would never tune it. At this level of space your pool is already running at degraded performance, by the way. Don't do that. > Regarding r268455, this is kind of a gotcha for people who are > running their pools close to full - should this be mentioned in > UPDATING or in the release notes? > > I understand that ZFS needs free space to be able to free more > space, but 3% of a large pool is a lot of bytes. Well, if you look at UFS, the reservation ratio is about 7.5% (8/108). File systems need free space to do allocation efficiently; even with mostly static contents, performance would suffer because at high level of space usage the file system would spend more time on looking up for free space and the resulted allocation is likely to be more fragmented. For ZFS, this means many essential operations like resilvering would be much slower, which is a real threat to data recoverability. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0 iQIcBAEBCgAGBQJUbAHFAAoJEJW2GBstM+nsy1cP/2LSiMfdINJFVThhOm23AQjc 0nAs7Z5FtahAHGlM5hJh2b5eaAqeVNh/Kc3Bf3egDVI9AQo7ZIUG2yR2BufMQ77O QbH2U4/wZRWm1Gw3QXhDpX37OjfcLFeopJ0ls3316ds7zfX4MXoHr/Zah+3gmrC2 3f7d7drmwTuIKYI22hQOiE72SYpZcJz3dFDc8ayn3JSLv5EOPxum7nVgrS1EgOps 4luP87wA6aR1sC4tMumsIHXPdqQJdSxPvClyzwAHDQu36f42myWQoJosgyTdmujK PoT/0RMVRs8tZkPBGejZVjumhkNAHWNs9glLhzReGy12Vvk8EVoV/AbvkFWSMO9l WS+6pwNCRYt7UWbl/uPdLwyd2+UpAzI+A/IFdNJAuxDK2KeAxaynVsvvmmtrH7JP JUt79yyDQmJhPribVqzMfjYp6oFJJHyEuQcMnrog2S+x/mx1Lz908Qk1Ox2izU5F SF3yK19ol+khYM1yDuF5ikiWHI0DJXtGPpEKeF82tpUhfgb7LYW2hITrFzdO5HfA BjhpX4y8lWlCub4Ji/275gTUCuKp5TDzSUqFn38uc/iG0IaV4jESENP/ZDA/PD64 RXS0nHjwBzvVHEWnD7fkEI8pzOY3iXvZMrnRjG4lL/RmkmmNSN50Q2vNRMn1tw1K TJu/wf7vrPMlwt0eLx+u =0Xf8 -----END PGP SIGNATURE-----