From owner-freebsd-stable@FreeBSD.ORG Mon Oct 13 23:02:25 2014 Return-Path: Delivered-To: freebsd-stable@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 D0CC0F3B for ; Mon, 13 Oct 2014 23:02:25 +0000 (UTC) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 83A01D30 for ; Mon, 13 Oct 2014 23:02:25 +0000 (UTC) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id s9DN2F91030438; Mon, 13 Oct 2014 16:02:19 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201410132302.s9DN2F91030438@gw.catspoiler.org> Date: Mon, 13 Oct 2014 16:02:15 -0700 (PDT) From: Don Lewis Subject: Re: getting to 4K disk blocks in ZFS To: cswiger@mac.com In-Reply-To: <77AA5757-5DC1-415B-899E-30545BF91516@mac.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org, lyndon@orthanc.ca 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: Mon, 13 Oct 2014 23:02:25 -0000 On 13 Oct, Charles Swiger wrote: > Hi-- > > 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. > > Or SSDs, which currently have anywhere from 2KB to 16KB "sectors". Which is even worse because you're more likely to care about wasted space because of the much higher cost per byte. > 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.