----- 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 SteveReceived on Sun Sep 21 2014 - 15:12:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:52 UTC