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] 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
