We're just working on this...

There's going to be an option (like that '--profile' mentioned above) that will switch amongst sets of different defaults that are suitable for different environments.

David, I've just committed the patchset upstream. I'll finish off the tests for our testsuite and complete the documentation... Then we can discuss how to integrate with anaconda etc...

Changing target version to F20/rawhide as F19 is not relevant now for this change.

The profile support is already in F20/rawhide since lvm2-2.02.99-1.fc20. We'll try to prepare some predefined profiles now...

(this is already in!)

The profiles are installed in /etc/lvm/profile directory. There's the "default.profile" installed which just lists all the items that are profilable and which can be used in profiles (either created by users or provided by us):

# This is a default profile for the LVM2 system.
# It contains all configuration settings that are customizable by profiles.
#
# To create a new profile, select the settings you want to customize
# and put them in a new file named <profile_name>.profile. Then put this
# file in a directory as defined by config/profile_dir setting found in
# /etc/lvm/lvm.conf file.
#
# Refer to 'man lvm.conf' for further information about profiles and file layout.

allocation {
	thin_pool_chunk_size = 64
	thin_pool_discards = "passdown"
	thin_pool_zero = 1
}

activation {
	thin_pool_autoextend_threshold = 100
	thin_pool_autoextend_percent = 20
}


Also, we've provided a "thin-performance.profile" which sets up thin provisioning for performance:

allocation {
	thin_pool_chunk_size_policy = "performance"
	thin_pool_zero = 0
}


(more tunables could be added later)

See also man lvm.conf(5), lvm(8), lvchange(8), vgchange(8) and vgs(8) for more information about profiles - the keyword to look for is "profile".

So what is the plan for this as it relates to the OS installer? Are you going to provide two or three profiles or are you expecting us to create them? All we need is one optimized for snapshots and one optimized for performance (the latter you have already provided).

We finally decided that the "many snapshots" profile is (at least at the moment) the one that we use now by default - so it's not a separate profile actually, but default thin settings used as it was before...

What the values of the default settings are for profilable configurables is listed in default.profile:

  https://git.fedorahosted.org/cgit/lvm2.git/tree/conf/default.profile.in

Where the thin_pool_chunk_size_policy values is one of (default is the "generic" one which applies to "many snapshots" scenario):

    # Specify chunk size calculation policy for thin pool volumes.
    # Possible options are:
    # "generic"        - if thin_pool_chunk_size is defined, use it.
    #                    Otherwise, calculate the chunk size based on
    #                    estimation and device hints exposed in sysfs:
    #                    the minimum_io_size. The chunk size is always
    #                    at least 64KiB.
    #    
    # "performance"    - if thin_pool_chunk_size is defined, use it.
    #                    Otherwise, calculate the chunk size for
    #                    performance based on device hints exposed in
    #                    sysfs: the optimal_io_size. The chunk size is
    #                    always at least 512KiB.

We haven't added more tunables yet, so this is all we provide at the moment. But I expect more to come in the (I hope near) future...

So now, by default, the minimum_io_size is always respected for the chunk size (if not overriden by directly setting the thin_pool_chunk_size to a certain value which always has more priority over any automatic calculation policy).

If the perfomarnce profile is used, the optimal_io_size is respected instead AND thin pools are not zeroed with this profile.

We haven't defined more profiles yet.

In order to provide GUI options for two distinct profiles we will need lvm to provide two distinct profiles. It does not matter if one of them is the default -- it should still exist as a named profile that anaconda/blivet can use by name. Otherwise we have to encode the knowledge that there is a hidden profile for snapshot performance.

OK, I'll add that then. It will be a copy of the part of the default lvm.conf we provide. But yes, it's true that people may need to change these settings in lvm.conf and still want to keep the original values in the profile...

"thin-generic.profile" added for generic/default settings:

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=8e0687ca690f9c5aa009e4b1963d46a03f8ba54c

Thanks!

David, is there a RFE Bug for Anaconda?

We would like to make sure the user will have three options available: using no profile (lvm.conf) or one of the provided profiles.

Indeed, there are three options available:
  - thin-generic profile (the defaults)
  - thin-performance profile
  - no profile attached (which then makes it behave based on current lvm.conf settings and those may differ from defaults if user changed that later; for anaconda this option is actually equal to using thin-generic profile as these are the defaults - anaconda environment doesn't use any lvm.conf so defaults are used for majority of things created unless overriden directly on cmd line)

*BUT* currently, the settings used in these profiles are only applicable for the pool itself while it's being created and it does not influence it after that when thins are created out of that pool. And anaconda just creates the pool/thins and it's done.

To provide the third option ("no profile attached") would be useful in anaconda's case only if anaconda created the VG, attached the profile to the VG (not the pool LV), then create the pool in that VG (assuming the pool inherits the VG's profile if no profile is specified for the pool LV) And then after installation, users could create  *another* pool in this VG and they can expect the same behaviour then as they selected during installation even if lvm.conf changed.

But I believe that anaconda is going to attach the profile to the pool LV, not the whole VG. So the third option ("no profile attached") is not quite useful at the moment. Such option would be more useful if there's a setting that may influence the pool's behaviour in run time, even after its creation, e.g. thin_pool_autoextend_threshold or thin_pool_autoextend_percent, which influence the monitoring functionality. But these are not currently used in thin-generic nor thin-performance profile as they're not about performance... And the profiles we provided are targeted on performance only.

(In reply to Peter Rajnoha from comment #14)
> that may influence the pool's behaviour in run time, even after its
> creation, e.g. thin_pool_autoextend_threshold or
> thin_pool_autoextend_percent, which influence the monitoring functionality.
> But these are not currently used in thin-generic nor thin-performance
> profile as they're not about performance...

(...well, they are also performance oriented in a way how often the autoextend happens which then consumes resources less or more over time... but we're not including them in the predefined profiles since it's hard to define what the best value is here - users add these in their own profiles based on what they actually need and how the pool is used. For these "autoextend" settings, there's no discrete value that would say "this is the best performance option" or not, while discrete value like "should the thin pool be zeroed" is clear - if zeroing is used, it's slower, but more secure and vice versa...)

So to sum it up and to answer the question whether we need to show the third option "no profile attached":
  - currently not as there's no use case for this
  - maybe in the future if we add some performance setting that has effect even after the pool is created (currently the settings we define in those profiles affect only how the pool is created, not it's runtime property)

Thanks Peter, you fully explained it.