From owner-freebsd-stable@FreeBSD.ORG Tue Oct 14 00:00:04 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BC569EBC; Tue, 14 Oct 2014 00:00:04 +0000 (UTC) Received: from isis.morrow.me.uk (isis.morrow.me.uk [204.109.63.142]) by mx1.freebsd.org (Postfix) with ESMTP id 973E66C6; Tue, 14 Oct 2014 00:00:04 +0000 (UTC) Received: from anubis.morrow.me.uk (unknown [93.89.81.46]) (Authenticated sender: mauzo) by isis.morrow.me.uk (Postfix) with ESMTPSA id 0C89645087; Mon, 13 Oct 2014 23:59:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.8.3 isis.morrow.me.uk 0C89645087 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=morrow.me.uk; s=dkim201101; t=1413244797; bh=3kdSKvOiavbBHJXX4Lt48JdMMoeL01rk+eq0i9+qMsE=; h=Date:From:To:Subject:References:In-Reply-To; b=bE4zuGevKufptt8y+4Lznat81ns+nsm+32BayxQrLDmLVkDiijOlPn7moA8eOS1sh 01cGYwtz2r4AH3u8T2Vv0WfBd+F88NMhseMf3GMCrJ9gaMpXtA3JbnPfnKHZoC2BbI UKdeBWEGzrka9C+kSUG76p1itZCFGp8pNa4/Gx/0= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.98.4 at isis.morrow.me.uk Received: by anubis.morrow.me.uk (Postfix, from userid 5001) id 7AFCF15701; Tue, 14 Oct 2014 00:59:53 +0100 (BST) Date: Tue, 14 Oct 2014 00:59:53 +0100 From: Ben Morrow To: truckman@FreeBSD.org, freebsd-stable@freebsd.org Subject: Re: getting to 4K disk blocks in ZFS Message-ID: <20141013235951.GA43024@anubis.morrow.me.uk> Mail-Followup-To: truckman@FreeBSD.org, freebsd-stable@freebsd.org References: <77AA5757-5DC1-415B-899E-30545BF91516@mac.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201410132302.s9DN2F91030438@gw.catspoiler.org> X-Newsgroups: gmane.os.freebsd.stable User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Oct 2014 00:00:04 -0000 Quoth Don Lewis : > On 13 Oct, Charles Swiger wrote: > > On Oct 13, 2014, at 2:25 PM, Lyndon Nerenberg > > wrote: > > [ ... ] > >> On any real-world system where you're running ZFS, it's unlikely the > >> 4K block overhead is really going to be an issue. And the underlying > >> disk hardware is moving to 4K physical sectors, anyway. Sooner or > >> later you're just going to have to suck it up. [...] > > > I suspect that MIX -- http://en.wikipedia.org/wiki/MIX_%28Email%29 -- > > will gain in popularity. Big messages are kept one per file, just as > > Maildir does, but MIX also does a pretty good job of conserving inodes > > (or equivalent) and minimizing wasted space from intrinsic > > fragmentation due to filesystem blocksize by aggregating small > > messages together. > > Interesting, but it would be nice to have a more generic solution that > could be used to solve the equivalent problem with /usr/ports and > similar sorts of things. For instance, it looks like /usr/src expands > by quite a bit on an ashift=12 raidz1, though not quite as much as my > mail spool. Put a UFS on a zvol? You get the raidz/snapshots of the zpool but since UFS uses fragments you should waste less space with small files. In principle ZFS could use fragments too, though the copy-on-write logic would end up looking exactly like SSD wear-levelling logic, and might be slow enough to be a problem. I don't know if anyone is working on this. (Does anyone know if zvols take notice of BIO_DELETE and return the space to the pool? In the raid case this would be a significant advantage for an fs with a lot of churn, like a frequently-updated /usr/src.) Ben