Hi Eric, Please see my replies inline below.
Thanks, Xing On 9/16/15, 1:20 PM, "Eric Harney" <ehar...@redhat.com> wrote: >On 09/15/2015 04:56 PM, yang, xing wrote: >> Hi Eric, >> >> Regarding the default max_over_subscription_ratio, I initially set the >> default to 1 while working on oversubscription, and changed it to 2 >>after >> getting review comments. After it was merged, I got feedback that 2 is >> too small and 20 is more appropriated, so I changed it to 20. So it >>looks >> like we can¹t find a default value that makes everyone happy. >> > >I'm curious about how this is used in real-world deployments. Are we >making the assumption that the admin has some external monitoring >configured to send alarms if the storage is nearing capacity? We can have Ceilometer integration for capacity notifications. See the following patches on capacity headroom: https://review.openstack.org/#/c/170380/ https://review.openstack.org/#/c/206923/ > >> If we can decide what is the best default value for LVM, we can change >>the >> default max_over_subscription_ratio, but we should also allow other >> drivers to specify a different config option if a different default >>value >> is more appropriate for them. > >This sounds like a good idea, I'm just not sure how to structure it yet >without creating a very confusing set of config options. I’m thinking we could have a prefix with vendor name for this and it also requires documentation by driver maintainers if they are using a different config option. I proposed a topic to discuss about this at the summit. > > >> On 9/15/15, 1:38 PM, "Eric Harney" <ehar...@redhat.com> wrote: >> >>> On 09/15/2015 01:00 PM, Chris Friesen wrote: >>>> I'm currently trying to work around an issue where activating LVM >>>> snapshots created through cinder takes potentially a long time. >>>> (Linearly related to the amount of data that differs between the >>>> original volume and the snapshot.) On one system I tested it took >>>>about >>>> one minute per 25GB of data, so the worst-case boot delay can become >>>> significant. >>>> >>>> According to Zdenek Kabelac on the LVM mailing list, LVM snapshots >>>>were >>>> not intended to be kept around indefinitely, they were supposed to be >>>> used only until the backup was taken and then deleted. He recommends >>>> using thin provisioning for long-lived snapshots due to differences in >>>> how the metadata is maintained. (He also says he's heard reports of >>>> volume activation taking half an hour, which is clearly crazy when >>>> instances are waiting to access their volumes.) >>>> >>>> Given the above, is there any reason why we couldn't make thin >>>> provisioning the default? >>>> >>> >>> >>> My intention is to move toward thin-provisioned LVM as the default -- >>>it >>> is definitely better suited to our use of LVM. Previously this was >>>less >>> easy, since some older Ubuntu platforms didn't support it, but in >>> Liberty we added the ability to specify lvm_type = "auto" [1] to use >>> thin if it is supported on the platform. >>> >>> The other issue preventing using thin by default is that we default the >>> max oversubscription ratio to 20. IMO that isn't a safe thing to do >>>for >>> the reference implementation, since it means that people who deploy >>> Cinder LVM on smaller storage configurations can easily fill up their >>> volume group and have things grind to halt. I think we want something >>> closer to the semantics of thick LVM for the default case. >>> >>> We haven't thought through a reasonable migration strategy for how to >>> handle that. I'm not sure we can change the default oversubscription >>> ratio without breaking deployments using other drivers. (Maybe I'm >>> wrong about this?) >>> >>> If we sort out that issue, I don't see any reason we can't switch over >>> in Mitaka. >>> >>> [1] https://review.openstack.org/#/c/104653/ >>> >>> >>>________________________________________________________________________ >>>__ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >>_________________________________________________________________________ >>_ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: >>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
