Date: Sun, 21 Sep 2014 13:51:22 -0400 From: Allan Jude <allanjude@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: zpool frag Message-ID: <541F101A.6000701@freebsd.org> In-Reply-To: <1965644.89SVIqCBMH@overcee.wemm.org> References: <1411289830171-5950788.post@n5.nabble.com> <1691600.4gjp5IhhyR@overcee.wemm.org> <C0CE9619A49C4DE3A7627362B886306F@multiplay.co.uk> <1965644.89SVIqCBMH@overcee.wemm.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 2014-09-21 13:39, Peter Wemm wrote: > On Sunday, September 21, 2014 06:12:09 PM Steven Hartland wrote: >> ----- 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. > > Hopefully so. The catch though is when its been run without it until recently > it can be a bit of a surprise. > > From an email exchange with George Wilson (developer of the spacemap_histogram feature): "You can use it on existing pools but the histogram only gets created when you condense a space_map (a process by which ZFS tries to make the space_map ondisk smaller). This means that when you look at an existing pool it may have some space_maps with histograms and ones without." This likely means that on a pool that has (recently??) been upgrade, the FRAG metric may fluctuate wildly, as more and more space_maps get a histogram. The histogram feature doesn't really solve the problem of fragmentation, it just makes the pool perform better when it is fragmented, as the pool can more reliably find the space_map containing the largest area of contiguous free space in order to maintain performance. -- Allan Jude [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUHxAeAAoJEJrBFpNRJZKf+sYP/3HoqWRfbj86sB6zIWJYgnAO 4U3hEMQlMljSTMptTwv+mR7Rj2wBxL/mIKyeNJD0agrJ+1FsHlahYcBwqrzPCq6S oGAlIPYLpBW3TL/lpS1XC6SyR34JJU4EFHDHqvMsXq47YLUTa9wd2IEsayvCRt9/ m2AteSpC16UEoALUXRRO97qThzbBmmtA0faMjQskL3wsNHfjb4MCG0YR0esge4cI ZdtxYM/1/GHYICzmFz67zjAYE8hrW/BAssXk07gEHD78zZe8Hvm6fsy5rP54o0Wa eC4OM0+wCStqq3yzLjvXIH5AailJOj5CtsDmCJBhqoBNGdVGfSvLmb/BrwKmFzyE IZ2tdOMa8R5Ymb8rul+7By3+3LoZgPnHIm2nPBjtWK75IeKsKTlE31xx4OYdF/Zn hWDAP5ERiLTn/Dq2dGNEDBRPUnNYPa9JbuhZ2LyWw44qOe2boeBi8wruy8T1tkbF lZWCbKbWwUZLrXpDYcqwHz+6iHVhLfgHhcm1x9fAfBaLTbCsxHqN85xEaCHZ047w imRnl1nr2AZD01G5tbuU7tnupen3usSx68IeSEfQSEdxbnO7vhAFPL9sBzHx31yq h5LFptYXqQcJ/GryhZg0C13TMadyXY4aMcWUUDDn9ZPE028Vgqv6s/JFWtrr8xgk 0SfSSJhRQtwjttt2EhZ+ =6SBK -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?541F101A.6000701>