getting to 4K disk blocks in ZFS

[Ben Morrow]

Quoth Don Lewis <truckman at FreeBSD.org>:
> On 13 Oct, Charles Swiger wrote:
> > On Oct 13, 2014, at 2:25 PM, Lyndon Nerenberg <lyndon at 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