Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Christopher Siden <christopher.siden <at> delphix.com>
Subject: spacemap/metaslab work
Newsgroups: gmane.os.illumos.zfs
Date: Wednesday 4th September 2013 03:44:02 UTC (over 3 years ago)
http://cr.illumos.org/~webrev/csiden/illumos-sm/

This is a metaslab/spacemap refactoring by George Wilson. See the full
list of bugs in the webrev for details. The highlights are:

- The spacemap code has been refactored to have separate data
structures for the on-disk data structure (called spacemaps in the new
code) and the in-memory data structure (called rangetrees in the new
code). This should aid in understanding the code.

- metaslab are preloaded asynchronously to avoid blocking on reads in
hot code paths when we realize we need to load new metaslabs. This has
shown to be a performance improvement in our performance testing.

- There is a new spacemap_histogram on-disk feature flag. When it is
enabled spacemaps store more data about the amount of contiguous free
space in metaslabs. The current disk format only stores the total
amount of free space, which means that heavily fragmented metaslabs
can look appealing, causing us to read them off disk, even though they
don't have enough contiguous free space to satisfy large allocations,
leading us to continually load the same fragmented space maps over and
over again. The allocation algorithm that uses this information is
disabled by default and can be enabled via a tunable. It will become
the default allocator once George is satisfied with the amount of
performance testing it has received. We have extensively tested this
code both with the tunable enabled and disabled. It is not possible to
seperate out spacemap_histogram from the rest of this refactoring
because they were done together.

Chris
 
CD: 3ms