vfs.zfs.metaslab.weight_factor_enable

[aufalien]

Hi,

Has any one messed with this variable?

Thoughts/opinions are welcome.

 

[DrKK]

No. Never heard of it.

What does it allege that it does?

 

[aufalien]

Well, I first heard of it here;

http://forums.freenas.org/index.php?threads/stripe-of-mirrors-expansion.17477/#post-93361

Read the 8th comment down by mpfusion. It looks to have something to do with optimizing free space on ZFS.

Some info I gleaned from an Illumos post;

- 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.

And an interesting discussion on it;

http://comments.gmane.org/gmane.os.illumos.zfs/2565

 

[DrKK]

Very interesting! Thanks for the information.

Being "bleeding edge" on FreeBSD is almost a contradiction in terms, so I think I'll wait until the gurus sign off on it.

 

[aufalien]

Yea, I just shot off a mailing list post so hopefully some one has tried it in production. Would be cool to have as a valid option. Seems like a very nice feature indeed.

 

[aufalien]

I posted on illumos and got a few pings, one of special note was from the developer of this feature flag who wrote;

The space_map histogram feature has been used in production at Delphix for a while. The data it provide is being used to make smarter decisions about how and where to allocate blocks. It also gives us an idea of how badly fragmented things get on a pool. For example, we've come up with a simplistic metric to define pool fragmentation based on the histogram information. Here's an example:

NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
dcenter 8.22T 5.50T 2.71T - 53% 66% 1.00x ONLINE -

The higher the frag% the more your free space is comprised of small segments. We have been making many changes in this area and more to come but the idea behind the histogram was to be able to lay the foundation for improvements in allocation strategies. You can take a closer look at the histogram on your pool by running 'zdb -mm[m] <pool>'.

Hope this helps. I will try to get a more extensive write up in a blog along with some of the perf enhancements we've seen by making smarter allocations decisions. Unfortunately right now I'm pretty busy with compressed ARC.

 

[aufalien]

Update, so in FreeNAS 9.2.1.7 the FRAG column doesn't exist.

However in 9.3 it does. And the variable is now called;

vfs.zfs.metaslab.fragmentation_factor_enabled

... and is enabled by default. Or, err, I think its been renamed to that as the original variable name no longer exists.