Date: Tue, 14 Oct 2014 00:59:53 +0100 From: Ben Morrow <ben@morrow.me.uk> 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> In-Reply-To: <201410132302.s9DN2F91030438@gw.catspoiler.org> References: <77AA5757-5DC1-415B-899E-30545BF91516@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Don Lewis <truckman@FreeBSD.org>: > On 13 Oct, Charles Swiger wrote: > > On Oct 13, 2014, at 2:25 PM, Lyndon Nerenberg <lyndon@orthanc.ca> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20141013235951.GA43024>