I think there's some mileage in some further work on adding local LVM, since things like striping/mirroring for performace can be done. We can prototype it and get the numbers before even thinking about merging though - as additions to an already fully featured driver. these seem more worthwhile a way forward than limping on with the bdd driver.
Moving to change our default target to LIO seems worthwhile - I'd suggest being cautious with deprecation rather than aggressive though - aiming to change the default in 'O' then planning the rest based on how that goes. On 19 September 2016 at 21:54, John Griffith <john.griffi...@gmail.com> wrote: > > > On Mon, Sep 19, 2016 at 12:01 PM, Ivan Kolodyazhny <e...@e0ne.info> wrote: > >> + [sahara] because they are primary consumer of the BDD. >> >> John, >> Thanks for the answer. My comments are inline. >> >> Regards, >> Ivan Kolodyazhny, >> http://blog.e0ne.info/ >> >> On Mon, Sep 19, 2016 at 4:41 PM, John Griffith <john.griffi...@gmail.com> >> wrote: >> >>> >>> >>> On Mon, Sep 19, 2016 at 4:43 AM, Ivan Kolodyazhny <e...@e0ne.info> >>> wrote: >>> >>>> Hi team, >>>> >>>> We did some performance tests [1] for LVM and BDD drivers. All tests >>>> were executed on real hardware with OpenStack Mitaka release. >>>> Unfortunately, we didn't have enough time to execute all tests and compare >>>> results. We used Sahara/Hadoop cluster with TestDFSIO and others >>>> tests. >>>> >>>> All tests were executed on the same hardware and OpenStack release. >>>> Only difference were in cinder.conf to enable needed backend and/or target >>>> driver. >>>> >>>> Tests were executed on following configurations: >>>> >>>> - LVM +TGT target >>>> - LVM+LocalTarget: PoC based on [2] spec >>>> - LVM+LIO >>>> - Block Device Driver. >>>> >>>> >>>> Feel free to ask question if any about our testing infrastructure, >>>> environment, etc. >>>> >>>> >>>> [1] https://docs.google.com/spreadsheets/d/1qS_ClylqdbtbrVSvwbbD >>>> pdWNf2lZPR_ndtW6n54GJX0/edit?usp=sharing >>>> [2] https://review.openstack.org/#/c/247880/ >>>> >>>> Regards, >>>> Ivan Kolodyazhny, >>>> http://blog.e0ne.info/ >>>> >>>> ____________________________________________________________ >>>> ______________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: openstack-dev-requ...@lists.op >>>> enstack.org?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> Thanks Ivan, so I'd like to propose we (the Cinder team) discuss a few >>> things (again): >>> >>> 1. Deprecate the BDD driver >>> Based on the data here LVM+LIO the delta in performance (with the >>> exception of the Terravalidate run against 3TB) doesn't seem significant >>> enough to warrant maintaining an additional driver that has only a subset >>> of features implemented. It would be good to understand why that >>> particular test has such a significant peformance gap. >>> >> What about Local Target? Does it make sense to implement it instead BDD? >> > Maybe I'm missing something, what would the advantage be? LVM+LIO and > LVM+LOCAL-TARGET seem pretty close. In the interest of simplicity and > maintenance just thinking maybe it would be worth considering just using > LVM+LIO across the board. > > > >> >>> 2. Consider getting buy off to move the default implementation to use >>> the LIO driver and consider deprecating the TGT driver >>> >> +1. Let's bring this topic for the next weekly meeting. >> >> >> >>> >>> I realize this probably isn't a sufficient enough data set to make those >>> two decisions but I think it's at least enough to have a more informed >>> discussion this time. >>> >>> Thanks, >>> John >>> >>> >>> ____________________________________________________________ >>> ______________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: openstack-dev-requ...@lists.op >>> enstack.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:unsubscrib >> e >> 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 > > -- -- Duncan Thomas
__________________________________________________________________________ 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