Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Sep 2014 18:12:09 +0100
From:      "Steven Hartland" <killing@multiplay.co.uk>
To:        "Peter Wemm" <peter@wemm.org>, <freebsd-current@freebsd.org>
Cc:        Allan Jude <allanjude@freebsd.org>
Subject:   Re: zpool frag
Message-ID:  <C0CE9619A49C4DE3A7627362B886306F@multiplay.co.uk>
References:  <1411289830171-5950788.post@n5.nabble.com> <541EE962.2000801@freebsd.org> <1691600.4gjp5IhhyR@overcee.wemm.org>

next in thread | previous in thread | raw e-mail | index | archive | help

----- Original Message ----- 
> From: "Peter Wemm" <peter@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C0CE9619A49C4DE3A7627362B886306F>