zpool frag

[Steven Hartland]

----- Original Message ----- 
> From: "Peter Wemm" <peter at wemm.org>
> On Sunday, September 21, 2014 11:06:10 AM Allan Jude wrote:
> > On 2014-09-21 04:57, Beeblebrox wrote:
> > > FRAG means fragmentation, right? Zpool fragmentation? That's news to me.
> > > If
> > > this is real how do I fix it?
> > > 
> > > NAME      SIZE  ALLOC   FREE   FRAG  EXPANDSZ    CAP  DEDUP  HEALTH 
> > > ALTROOT pool1      75.5G  53.7G  21.8G    60%         -    71%  1.00x 
> > > ONLINE  - pool2      48.8G  26.2G  22.6G    68%         -    53%  1.00x 
> > > ONLINE  - pool3       204G   177G  27.0G    53%         -    86%  1.11x 
> > > ONLINE  -
> > It is not something you 'fix', it is just a metric to help you
> > understand the performance of your pool. The higher the fragmentation,
> > the longer it might take to allocate new space, and obviously you will
> > have more random seek time while reading from the pool.
> > 
> > As Steven mentions, there is no defragmentation tool for ZFS. You can
> > zfs send/recv or backup/restore the pool if you have a strong enough
> > reason to want to get the fragmentation number down.
> > 
> > It is a fairly natural side effect of a copy-on-write file system.
> > 
> > Note: the % is not the % fragmented, IIRC, it is the percentage of the
> > free blocks that are less that a specific size. I forget what that size is.
> 
> I fear that the information presented in its current form is going to generate 
> lots of fear and confusion.
> 
> The other thing to consider is that this gets much, much worse as the pool 
> fills up.  Even UFS has issues with fragmentation when it fills, but ZFS is far 
> more sensative to it.  In the freebsd.org cluster we have a health check alert 
> at 80% full, but even that's probably on the high side.

This "should" be less of an issue if you have the spacemap_histogram feature
enabled on the pool, which IIRC if your seeing FRAG details should be the case.

    Regards
    Steve