Bug 958464 - RFE: Simplify specification of primary thinp usage profiles
RFE: Simplify specification of primary thinp usage profiles
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Peter Rajnoha
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-01 10:49 EDT by David Lehman
Modified: 2014-06-25 09:25 EDT (History)
12 users (show)

See Also:
Fixed In Version: lvm2-2.02.107-1.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-24 05:55:53 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description David Lehman 2013-05-01 10:49:08 EDT
Description of problem:
Some things users might want to control at OS installation time for thinp include pool metadata size and chunk size. If we were to add support for any of this to anaconda it would need to be in a simple format like --profile=write-heavy or whatever as opposed to specifying exact numbers and then having people file bugs that they'd prefer we tweak those numbers, &c.

Perhaps someone could provide a summary of the major configurable items, whether each can be modified after the pool has been created, and any other relevant information as a starting point.
Comment 1 Peter Rajnoha 2013-05-02 04:19:47 EDT
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.
Comment 2 Peter Rajnoha 2013-07-02 10:22:58 EDT
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...
Comment 3 Peter Rajnoha 2013-08-21 04:07:48 EDT
Changing target version to F20/rawhide as F19 is not relevant now for this change.
Comment 4 Peter Rajnoha 2013-08-21 04:11:41 EDT
The profile support is already in F20/rawhide since lvm2-2.02.99-1.fc20. We'll try to prepare some predefined profiles now...
Comment 5 Peter Rajnoha 2013-11-05 09:34:39 EST
(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".
Comment 6 David Lehman 2013-11-05 10:37:02 EST
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).
Comment 7 Peter Rajnoha 2013-11-06 07:34:55 EST
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...
Comment 8 Peter Rajnoha 2013-11-06 07:38:48 EST
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.
Comment 9 David Lehman 2014-06-11 11:42:57 EDT
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.
Comment 10 Peter Rajnoha 2014-06-13 02:32:30 EDT
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...
Comment 11 Peter Rajnoha 2014-06-13 04:03:33 EDT
"thin-generic.profile" added for generic/default settings:

https://git.fedorahosted.org/cgit/lvm2.git/commit/?id=8e0687ca690f9c5aa009e4b1963d46a03f8ba54c
Comment 12 David Lehman 2014-06-24 11:55:01 EDT
Thanks!
Comment 13 Marian Csontos 2014-06-25 08:08:33 EDT
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.
Comment 14 Peter Rajnoha 2014-06-25 08:38:02 EDT
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.
Comment 15 Peter Rajnoha 2014-06-25 08:46:25 EDT
(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...)
Comment 16 Peter Rajnoha 2014-06-25 08:49:04 EDT
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)
Comment 17 Marian Csontos 2014-06-25 09:25:47 EDT
Thanks Peter, you fully explained it.

Note You need to log in before you can comment on or make changes to this bug.