----- Original Message -----
From: "Peter Wemm" <pe...@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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"