Date: Sun, 21 Sep 2014 10:39:43 -0700 From: Peter Wemm <peter@wemm.org> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-current@freebsd.org, Allan Jude <allanjude@freebsd.org> Subject: Re: zpool frag Message-ID: <1965644.89SVIqCBMH@overcee.wemm.org> In-Reply-To: <C0CE9619A49C4DE3A7627362B886306F@multiplay.co.uk> References: <1411289830171-5950788.post@n5.nabble.com> <1691600.4gjp5IhhyR@overcee.wemm.org> <C0CE9619A49C4DE3A7627362B886306F@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2047581.7hXjsinto4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Sunday, September 21, 2014 06:12:09 PM Steven Hartland wrote: > ----- Original Message ----- >=20 > > From: "Peter Wemm" <peter@wemm.org> > >=20 > > 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 ne= ws to > > > > me. > > > > If > > > > this is real how do I fix it? > > > >=20 > > > > NAME SIZE ALLOC FREE FRAG EXPANDSZ CAP DEDUP HE= ALTH > > > > ALTROOT pool1 75.5G 53.7G 21.8G 60% - 71% = 1.00x > > > > ONLINE - pool2 48.8G 26.2G 22.6G 68% - 53= %=20 > > > > 1.00x > > > > ONLINE - pool3 204G 177G 27.0G 53% - 86= %=20 > > > > 1.11x > > > > ONLINE - > > >=20 > > > It is not something you 'fix', it is just a metric to help you > > > understand the performance of your pool. The higher the fragmenta= tion, > > > the longer it might take to allocate new space, and obviously you= will > > > have more random seek time while reading from the pool. > > >=20 > > > 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 eno= ugh > > > reason to want to get the fragmentation number down. > > >=20 > > > It is a fairly natural side effect of a copy-on-write file system= . > > >=20 > > > Note: the % is not the % fragmented, IIRC, it is the percentage o= f the > > > free blocks that are less that a specific size. I forget what tha= t size > > > is. > >=20 > > I fear that the information presented in its current form is going = to > > generate lots of fear and confusion. > >=20 > > The other thing to consider is that this gets much, much worse as t= he pool > > fills up. Even UFS has issues with fragmentation when it fills, bu= t 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.= >=20 > 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. Hopefully so. The catch though is when its been run without it until r= ecently=20 it can be a bit of a surprise. =2D-=20 Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI= 6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 --nextPart2047581.7hXjsinto4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAABAgAGBQJUHw1oAAoJEDXWlwnsgJ4EPbAIALjgkSFKIi2eOjvpOpvN0Fa4 +MLbgW8aprpLO6tQYvshi77cDa4CCoshnQhAqfp+5lSPFDXB9TZh3awl2fmynEhk YODto3xsqJpAlJXAYV0LANCQD0/Cb3jZ9LAywuPjHoYzLwAN7JGT7ocUUWsXWUnh cI3y9I6+oAq1BWbM/L68p2dAmWKm3AsWQlQuIHCoYNBzizalNtLoE7Pu/m6w1GnG AxKHq486EprDRjU09RIPkndrkYSe18/WUYNtFfZ/Ees+qtyUvan4KmJkbuuBWCjG PsO63ZVpxM5WJ57OqWNORy/yhL8xbADIDCy+ttYCikKwLdiolHHmY5yHIVrcaVw= =zt04 -----END PGP SIGNATURE----- --nextPart2047581.7hXjsinto4--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1965644.89SVIqCBMH>