Skip to content

Commit

Permalink
Describe the fragmentation metric in zpool.8
Browse files Browse the repository at this point in the history 
While it's commonly understood that a larger fragmentation value
is worse than a smaller one it is never explained anywhere but
the source what this value means.  Using the comment in the source
add this information to the zpool.8 man page.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
  • Loading branch information
@behlendorf
behlendorf committed Dec 9, 2015
1 parent 24ef51f commit 3235065
Showing 1 changed file with 32 additions and 0 deletions.
32 changes: 32 additions & 0 deletions man/man8/zpool.8
View file
Original file line number Diff line number Diff line change
Expand Up @@ -516,6 +516,38 @@ any space on an EFI labeled vdev which has not been brought online
.RS 20n
.rt
The amount of fragmentation in the pool.

This comment has been minimized.

Sign in to view

Copy link
@dweeezil

dweeezil Dec 9, 2015

Contributor

Maybe this ought to say "The fragmentation metric, expressed as a percentage, of the pool described below. It is not, directly, a percentage of anything but is a metric in which the value is inversely proportional to the amount of contiguous free space available". This could lead into the internals discussion below.
.sp
.LP
This table defines a segment size based fragmentation metric that will
allow each metaslab to derive its own fragmentation value. This is done
by calculating the space in each bucket of the spacemap histogram and
multiplying that by the fragmetation metric in this table. Doing
this for all buckets and dividing it by the total amount of free
space in this metaslab (i.e. the total free space in all buckets) gives
us the fragmentation metric. This means that a high fragmentation metric
equates to most of the free space being comprised of small segments.
Conversely, if the metric is low, then most of the free space is in
large segments. A 10% change in fragmentation equates to approximately
double the number of segments.
.sp
.LP
This table defines 0% fragmented space using 16MB segments. Testing has
shown that segments that are greater than or equal to 16MB do not suffer
from drastic performance problems. Using this value, we derive the rest
of the table. Since the fragmentation value is never stored on disk, it
is possible to change these calculations in the future.
.sp
.in +2
.nf
metric segment metric segment metric segment
0% 16M 30% 512K 80% 16K
5% 8M 40% 256K 90% 8K
10% 4M 50% 128K 95% 4K
15% 2M 60% 64K 98% 2K
20% 1M 70% 32K 100% 1K
.fi
.in -2
.sp
.RE

.sp
Expand Down

1 comment on commit 3235065

@dweeezil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm glad to see this getting addressed but I think a bit more explanation is warranted as to how the overall pool fragmentation is calculated. The text above, taken from the code comments, relate to a single metaslab but doesn't really give the big picture as to how the single metric displayed to the user is calculated.

Please sign in to comment.