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>