On Fri, Jan 6, 2017 at 11:38 AM, kefu chai <tchaikov@xxxxxxxxx> wrote: > hi cephers, > > libcommon is a convenient library and is statically linked into > librados, librbd and libcephfs. and there are some static variables > living in libcommon, for instance, the ones defined in lockdep.cc. so, > we will have multiple copies of these global variables if an > application is linked against librados and (librbd | libcephfs). the > "ceph" cli does link against librados and libcephfs via the their > python bindings. > > this incurs some problems: > > - cross reference each other's global variables: in my testbed, i ran > into https://github.com/ceph/ceph/pull/12249#issuecomment-264105597. > where libcephfs was referencing the lockdeps variables in librados > when relinquishing a lock. when libcephfs tries to acquire this lock > again, it found that this lock is *already* locked. > - more memory foot print and disk space: apparently, libcommon is > included by librados, librbd and libcephfs. so it's a waste to have > multiple copies of libcommon if librbd and/or libcephfs are loaded > into memory or installed onto disk. > > after turning libcommon into a shared library, these problems are solved. > > but yes, unlike librados and its friends, libcommon is not a user > facing library, so we will not install it right under /usr/lib/. > instead, it will be living in /usr/lib/ceph. please note, the erasure > plugins are installed into /usr/lib/ceph/erasure-code/ and rados > classes are installed into /usr/lib/rados-classes/. this follows the > related section of FHS [1]. > > what do you think? +1 John > > -- > [1] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA > > -- > Regards > Kefu Chai > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
