August 2023 - Dev - lists.ceph.io

by steve jung

Hello In order to reduce the rebalacing load when removing the disk, a test was conducted to adjust the reweight value of the OSD. When the OSD reweight value was set to 0 during the test, an assert fail occurred in the MGR when the OSD was not in the down state. (It was a phenomenon that MGR went down after restarting was attempted 3 times) Regardless of the OSD status, even if the OSD reweight value is set to 0, MGR should not be affected. Is there anything you would like to share about this? Below is the output log contents and related code parts. [Ceph crash info] ------------------------------------------------------------------------------ { "archived": "2023-07-25 07:57:04.772224", "assert_condition": "osd_weight.count(oid)", "assert_file": "/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos8/DIST/centos8/MACHINE_SIZE/gigantic/release/17.2.3/rpm/el8/BUILD/ceph-17.2.3/src/osd/OSDMap.cc", "assert_func": "float OSDMap::calc_deviations(ceph::common::CephContext*, const std::map<int, std::set<pg_t> >&, const std::map<int, float>&, float, std::map<int, float>&, std::multimap<float, int>&, float&)", "assert_line": 5155, "assert_msg": "/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos8/DIST/centos8/MACHINE_SIZE/gigantic/release/17.2.3/rpm/el8/BUILD/ceph-17.2.3/src/osd/OSDMap.cc: In function 'float OSDMap::calc_deviations(ceph::common::CephContext*, const std::map<int, std::set<pg_t> >&, const std::map<int, float>&, float, std::map<int, float>&, std::multimap<float, int>&, float&)' thread 7f56bf420700 time 2023-07-25T07:49:30.155196+0000\n/home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos8/DIST/centos8/MACHINE_SIZE/gigantic/release/17.2.3/rpm/el8/BUILD/ceph-17.2.3/src/osd/OSDMap.cc: 5155: FAILED ceph_assert(osd_weight.count(oid))\n", "assert_thread_name": "balancer", "backtrace": [ "/lib64/libpthread.so.0(+0x12ce0) [0x7f570b3c3ce0]", "gsignal()", "abort()", "(ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x1b0) [0x7f570c5a4cd2]", "/usr/lib64/ceph/libceph-common.so.2(+0x283e95) [0x7f570c5a4e95]", "(OSDMap::calc_deviations(ceph::common::CephContext*, std::map<int, std::set<pg_t, std::less<pg_t>, std::allocator<pg_t> >, std::less<int>, std::allocator<std::pair<int const, std::set<pg_t, std::less<pg_t>, std::allocator<pg_t> > > > > const&, std::map<int, float, std::less<int>, std::allocator<std::pair<int const, float> > > const&, float, std::map<int, float, std::less<int>, std::allocator<std::pair<int const, float> > >&, std::multimap<float, int, std::less<float>, std::allocator<std::pair<float const, int> > >&, float&)+0xe0) [0x7f570ca71490]", "(OSDMap::calc_pg_upmaps(ceph::common::CephContext*, unsigned int, int, std::set<long, std::less<long>, std::allocator<long> > const&, OSDMap::Incremental*, unsigned int*)+0x389) [0x7f570ca75829]", "/usr/bin/ceph-mgr(+0x299406) [0x555f39368406]", "/lib64/libpython3.6m.so.1.0(+0x19d0d7) [0x7f570d4d80d7]", "_PyEval_EvalFrameDefault()", "/lib64/libpython3.6m.so.1.0(+0xf9984) [0x7f570d434984]", "/lib64/libpython3.6m.so.1.0(+0x17a030) [0x7f570d4b5030]", "/lib64/libpython3.6m.so.1.0(+0x19d377) [0x7f570d4d8377]", "_PyEval_EvalFrameDefault()", "/lib64/libpython3.6m.so.1.0(+0x179e48) [0x7f570d4b4e48]", "/lib64/libpython3.6m.so.1.0(+0x19d377) [0x7f570d4d8377]", "_PyEval_EvalFrameDefault()", "/lib64/libpython3.6m.so.1.0(+0x179e48) [0x7f570d4b4e48]", "/lib64/libpython3.6m.so.1.0(+0x19d377) [0x7f570d4d8377]", "_PyEval_EvalFrameDefault()", "/lib64/libpython3.6m.so.1.0(+0xfa2f6) [0x7f570d4352f6]", "_PyFunction_FastCallDict()", "_PyObject_FastCallDict()", "/lib64/libpython3.6m.so.1.0(+0x10db30) [0x7f570d448b30]", "_PyObject_FastCallDict()", "PyObject_CallMethod()", "(PyModuleRunner::serve()+0x66) [0x555f39363e06]", "(PyModuleRunner::PyModuleRunnerThread::entry()+0x3e3) [0x555f39365443]", "/lib64/libpthread.so.0(+0x81ca) [0x7f570b3b91ca]", "clone()" ], "ceph_version": "17.2.3", "crash_id": "2023-07-25T07:49:30.158977Z_893ea7cd-a5d9-4e57-9ea0-86978b1300cf", "entity_name": "mgr.eyb-ceph-01.axqecw", "os_id": "centos", "os_name": "CentOS Stream", "os_version": "8", "os_version_id": "8", "process_name": "ceph-mgr", "stack_sig": "4195797c9f0eefb87056e4b2697fb9367d000d73fc09bdea7f52dbe5b600ccca", "timestamp": "2023-07-25T07:49:30.158977Z", "utsname_hostname": "eyb-ceph-01", "utsname_machine": "x86_64", "utsname_release": "5.4.0-125-generic", "utsname_sysname": "Linux", "utsname_version": "#141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022" } [MGR Log] /var/log/ceph/<fsid>/ceph-mgr*.log ------------------------------------------------------------------------------ 2023-08-22T11:06:56.402+0000 7fbf43d5e700 0 [balancer INFO root] Optimize plan auto_2023-08-22_11:06:56 2023-08-22T11:06:56.402+0000 7fbf43d5e700 0 [balancer INFO root] Mode upmap, max misplaced 0.050000 2023-08-22T11:06:56.402+0000 7fbf43d5e700 0 [balancer INFO root] do_upmap 2023-08-22T11:06:56.402+0000 7fbf43d5e700 0 [balancer INFO root] pools ['rp3pool', 'ec195-4k-pool', 'default.rgw.log', 'ec93pool-rbd', 'suwon.bucket.index', 'default.rgw.buckets.index', '.rgw.root', 'ec93-non-stripe-pool', 'default.rgw.control', '.mgr', 'default.rgw.meta', 'default.rgw.otp', 'default.rgw.buckets.non-ec', 'ec195-64k-pool', 'ec195-16k-pool'] 2023-08-22T11:06:56.450+0000 7fbf43d5e700 -1 /home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos8/DIST/centos8/MACHINE_SIZE/gigantic/release/17.2.3/rpm/el8/BUILD/ceph-17.2.3/src/osd/OSDMap.cc: In function 'float OSDMap::calc_deviations(ceph::common::CephContext*, const std::map<int, std::set<pg_t> >&, const std::map<int, float>&, float, std::map<int, float>&, std::multimap<float, int>&, float&)' thread 7fbf43d5e700 time 2023-08-22T11:06:56.450708+0000 /home/jenkins-build/build/workspace/ceph-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos8/DIST/centos8/MACHINE_SIZE/gigantic/release/17.2.3/rpm/el8/BUILD/ceph-17.2.3/src/osd/OSDMap.cc: 5155: FAILED ceph_assert(osd_weight.count(oid)) ceph version 17.2.3 (dff484dfc9e19a9819f375586300b3b79d80034d) quincy (stable) 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x152) [0x7fbfadff5c74] 2: /usr/lib64/ceph/libceph-common.so.2(+0x283e95) [0x7fbfadff5e95] 3: (OSDMap::calc_deviations(ceph::common::CephContext*, std::map<int, std::set<pg_t, std::less<pg_t>, std::allocator<pg_t> >, std::less<int>, std::allocator<std::pair<int const, std::set<pg_t, std::less<pg_t>, std::allocator<pg_t> > > > > const&, std::map<int, float, std::less<int>, std::allocator<std::pair<int const, float> > > const&, float, std::map<int, float, std::less<int>, std::allocator<std::pair<int const, float> > >&, std::multimap<float, int, std::less<float>, std::allocator<std::pair<float const, int> > >&, float&)+0xe0) [0x7fbfae4c2490] 4: (OSDMap::calc_pg_upmaps(ceph::common::CephContext*, unsigned int, int, std::set<long, std::less<long>, std::allocator<long> > const&, OSDMap::Incremental*, unsigned int*)+0x389) [0x7fbfae4c6829] 5: /usr/bin/ceph-mgr(+0x299406) [0x55e50358a406] 6: /lib64/libpython3.6m.so.1.0(+0x19d0d7) [0x7fbfaef290d7] 7: _PyEval_EvalFrameDefault() 8: /lib64/libpython3.6m.so.1.0(+0xf9984) [0x7fbfaee85984] 9: /lib64/libpython3.6m.so.1.0(+0x17a030) [0x7fbfaef06030] 10: /lib64/libpython3.6m.so.1.0(+0x19d377) [0x7fbfaef29377] 11: _PyEval_EvalFrameDefault() 12: /lib64/libpython3.6m.so.1.0(+0x179e48) [0x7fbfaef05e48] 13: /lib64/libpython3.6m.so.1.0(+0x19d377) [0x7fbfaef29377] 14: _PyEval_EvalFrameDefault() 15: /lib64/libpython3.6m.so.1.0(+0x179e48) [0x7fbfaef05e48] 16: /lib64/libpython3.6m.so.1.0(+0x19d377) [0x7fbfaef29377] 17: _PyEval_EvalFrameDefault() 18: /lib64/libpython3.6m.so.1.0(+0xfa2f6) [0x7fbfaee862f6] 19: _PyFunction_FastCallDict() 20: _PyObject_FastCallDict() 21: /lib64/libpython3.6m.so.1.0(+0x10db30) [0x7fbfaee99b30] 22: _PyObject_FastCallDict() 23: PyObject_CallMethod() 24: (PyModuleRunner::serve()+0x66) [0x55e503585e06] 25: (PyModuleRunner::PyModuleRunnerThread::entry()+0x3e3) [0x55e503587443] 26: /lib64/libpthread.so.0(+0x81ca) [0x7fbface0a1ca] 27: clone() 2023-08-22T11:06:56.450+0000 7fbf43d5e700 -1 *** Caught signal (Aborted) ** in thread 7fbf43d5e700 thread_name:balancer ceph version 17.2.3 (dff484dfc9e19a9819f375586300b3b79d80034d) quincy (stable) 1: /lib64/libpthread.so.0(+0x12ce0) [0x7fbface14ce0] 2: gsignal() 3: abort() 4: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x1b0) [0x7fbfadff5cd2] 5: /usr/lib64/ceph/libceph-common.so.2(+0x283e95) [0x7fbfadff5e95] 6: (OSDMap::calc_deviations(ceph::common::CephContext*, std::map<int, std::set<pg_t, std::less<pg_t>, std::allocator<pg_t> >, std::less<int>, std::allocator<std::pair<int const, std::set<pg_t, std::less<pg_t>, std::allocator<pg_t> > > > > const&, std::map<int, float, std::less<int>, std::allocator<std::pair<int const, float> > > const&, float, std::map<int, float, std::less<int>, std::allocator<std::pair<int const, float> > >&, std::multimap<float, int, std::less<float>, std::allocator<std::pair<float const, int> > >&, float&)+0xe0) [0x7fbfae4c2490] 7: (OSDMap::calc_pg_upmaps(ceph::common::CephContext*, unsigned int, int, std::set<long, std::less<long>, std::allocator<long> > const&, OSDMap::Incremental*, unsigned int*)+0x389) [0x7fbfae4c6829] 8: /usr/bin/ceph-mgr(+0x299406) [0x55e50358a406] [Related code] OSDMap.cc ------------------------------------------------------------------------------ float OSDMap::calc_deviations ( CephContext *cct, const map<int,set<pg_t>>& pgs_by_osd, const map<int,float>& osd_weight, float pgs_per_weight, map<int,float>& osd_deviation, multimap<float,int>& deviation_osd, float& stddev) // return current max deviation { // // This function calculates the 2 maps osd_deviation and deviation_osd which // hold the deviation between the current number of PGs which map to an OSD // and the optimal number. Ot also calculates the stddev of the deviations and // returns the current max deviation. // NOTE - the calculation is not exactly stddev it is actually sttdev^2 but as // long as it is monotonic with stddev (and it is), it is sufficient for // the balancer code. // float cur_max_deviation = 0.0; stddev = 0.0; for (auto& [oid, opgs] : pgs_by_osd) { // make sure osd is still there (belongs to this crush-tree) ceph_assert(osd_weight.count(oid)); float target = osd_weight.at(oid) * pgs_per_weight; float deviation = (float)opgs.size() - target; ldout(cct, 20) << " osd." << oid << "\tpgs " << opgs.size() << "\ttarget " << target << "\tdeviation " << deviation << dendl; osd_deviation[oid] = deviation; deviation_osd.insert(make_pair(deviation, oid)); stddev += deviation * deviation; if (fabsf(deviation) > cur_max_deviation) cur_max_deviation = fabsf(deviation); } return cur_max_deviation; }

8 months, 2 weeks

1
0
0 0

Restricted access to /teuthology on teuthology.front.sepia.ceph.com

by Patrick Donnelly

Hi folks, As many of you are aware, RAM/CPU is particularly scarce on teuthology.front.sepia.ceph.com which means that any log viewing of QA results can cause swapping and general slowness. At today's Ceph Infrastructure Weekly call [1], I proposed only allowing root, www-data, and teuthworker access to /teuthology so that others would be forced to look at logs on other beefier development machines like senta [2], vossi [3], your personal workstation [4], or even some temporary locked node [5]. The current plan is to proceed barring some reasonable justification not to. There are a few to-do items to make it happen laid out in the minutes. Until then, admins of teuthology would appreciate it if you already start moving your log viewing to other machines without waiting for a technical barrier to be set up. [1] https://pad.ceph.com/p/ceph-infra-weekly [2] https://wiki.sepia.ceph.com/doku.php?id=hardware:senta [3] https://wiki.sepia.ceph.com/doku.php?id=hardware:vossi [4] https://wiki.sepia.ceph.com/doku.php?id=services:cephfs [5] https://wiki.sepia.ceph.com/doku.php?id=testnodeaccess -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D

8 months, 2 weeks

1
0
0 0

Re: rgw: interest in isa-l_crypto for md5 acceleration

by Casey Bodley

thanks Chunmei (and cc ceph dev list), "RGWPutObj uses async_md5 for ETag" is a first draft at hooking this up for rgw, and the pr description in https://github.com/ceph/ceph/pull/52488 includes a todo list for further work the first step is to run this async hashing in parallel with filter->process(), which is what applies compression/encryption and ultimately writes the data to rados. ideally this would mask most of the latency from md5 the pr adds a single instance of async_md5::Batch that runs on a strand executor of rgw's thread pool. this means the md5 calculations can run on any available thread, but will only utilize one core at a time. we might improve utilization by adding more Batch instances, but that could reduce the probability that rgw requests can fill those batches within the "batch timeout". this timeout is a free parameter that would need tuning i'd like to determine how effective one instance is at offloading the md5 calculations. if the md5 part (almost) always completes before filter->process() does, that's probably good enough. if not, we'd want a way to scale the number of instances based on latency or load unfortunately, Mark and i are seeing crashes while testing this rgw integration. i added a comment about this in https://github.com/ceph/ceph/pull/52385#pullrequestreview-1578597699, and will follow up there finally, regarding the base async/batching library in https://github.com/ceph/ceph/pull/52385, i'd like to explore ways to extend that to cover other types of hashes and other libraries like QAT. do you think QAT would work well under the same async/batching interface? overall, does this sound like a reasonable design for rgw? On Mon, Aug 14, 2023 at 5:52 PM Liu, Chunmei <chunmei.liu(a)intel.com> wrote: > > Hi Casey, > > In your following two PRS: > https://github.com/ceph/ceph/pull/52385 builds an asynchronous batching library on top of the isal crypto library's multi-buffer md5 facilities: > https://github.com/ceph/ceph/pull/52488 rgw/op: RGWPutObj uses async_md5 for ETag. > Seems rgw can do async md5 batching. I am wondering what the current work status is. If all features are implemented or still has other features need to be implemented in next step? What can intel team help here? > > Thanks! > -Chunmei > > > -----Original Message----- > > From: Cheng, Yingxin <yingxin.cheng(a)intel.com> > > Sent: Thursday, August 10, 2023 10:32 PM > > To: Casey Bodley <cbodley(a)redhat.com>; Liu, Chunmei > > <chunmei.liu(a)intel.com>; Feng, Hualong <hualong.feng(a)intel.com> > > Cc: Tang, Guifeng <guifeng.tang(a)intel.com>; mbenjami > > <mbenjami(a)redhat.com>; Mark Kogan <mkogan(a)redhat.com>; Marcus > > Watts <mwatts(a)redhat.com>; Gabriel BenHanokh <gbenhano(a)redhat.com> > > Subject: RE: rgw: interest in isa-l_crypto for md5 acceleration > > > > Include Chunmei. > > > > Regards, > > -Yingxin > > > > > -----Original Message----- > > > From: Cheng, Yingxin > > > Sent: Thursday, July 13, 2023 3:54 PM > > > To: Casey Bodley <cbodley(a)redhat.com>; Feng, Hualong > > > <hualong.feng(a)intel.com> > > > Cc: Tang, Guifeng <guifeng.tang(a)intel.com>; mbenjami > > > <mbenjami(a)redhat.com>; Mark Kogan <mkogan(a)redhat.com>; Marcus > > Watts > > > <mwatts(a)redhat.com>; Gabriel BenHanokh <gbenhano(a)redhat.com> > > > Subject: RE: rgw: interest in isa-l_crypto for md5 acceleration > > > > > > Merge another RGW thread here, it is discussing the same thing. > > > > > > I'm also learning and try to answer below: > > > > > > > But when less than 100% CPU is running, using AVX512 to save core > > > > may cause > > > slowdown. > > > > > > > well put, this is the part i'm struggling with too. it feels like a > > > > tradeoff between cpu usage and added latency (both from thread > > > > synchronization and waiting for full batches) > > > > > > Yeah, there are synthetic effects from both software and hardware: > > > latency vs batching, CPU downclocking (should have less impacts from > > > later CPU models such as SPR), sync vs async, etc. > > > > > > > I'm not sure if the current work is an informed implementation with > > > > respect to > > > the isa-l interface; I'm fairly sure it is with regard to boost::asio > > > and related topics. > > > > > > My understanding is that the asynchronous way has the best opportunity > > > to fully use the 16 lane AVX512 accelerations by batching the > > > requests, and falling back to the synchronous way is worth considering > > > under small sizes or low depth. But the decisions need to be based on real > > test results. > > > > > > > Is there anything we can do to spread the load evenly on > > > SSE/AVX/AVX2/AVX512 units? > > > > I assume that each physical core has a standalone unit - can we make > > > > sure to > > > employee them all in parallel? > > > > > > SIMD are CPU instructions rather than off-loadable device. They can > > > only be executed from a thread synchronously. So if the parallelism > > > exceeds 16 lanes, it should be reasonable to start another worker > > > thread. And if there are only 8 outstanding lanes at the moment, AVX2 > > > should be a better choice rather than the heavier AVX512. I'm not sure > > > yet whether isa-l library is intelligent enough to pick the right instruction or > > it is manually controlled. > > > > > > > This handles only MD5, which certainly matters to us, but I suspect > > > > we strongly > > > need acceleration for sha-256 and sha-512. > > > > > > Looks isa-l supports these optimizations, which is the recommended way > > > because there might be multiple options available at the same time (AVX512 > > and sha-ni). > > > Looking at the source code, the library is able to detect the > > > availability and select the best possible option. > > > > > > Regards, > > > -Yingxin > > > > > > > -----Original Message----- > > > > From: Casey Bodley <cbodley(a)redhat.com> > > > > Sent: Thursday, July 13, 2023 3:19 AM > > > > To: Feng, Hualong <hualong.feng(a)intel.com> > > > > Cc: Cheng, Yingxin <yingxin.cheng(a)intel.com>; Tang, Guifeng > > > > <guifeng.tang(a)intel.com>; mbenjami <mbenjami(a)redhat.com>; Mark > > Kogan > > > > <mkogan(a)redhat.com> > > > > Subject: Re: rgw: interest in isa-l_crypto for md5 acceleration > > > > > > > > thanks Hualong, (cc Matt and Mark) > > > > > > > > On Wed, Jul 12, 2023 at 6:22 AM Feng, Hualong > > > > <hualong.feng(a)intel.com> > > > > wrote: > > > > > > > > > > Hi Casey > > > > > > > > > > Our team are interested in this, but we need to study more details. > > > > > > > > > > We have learned about md5 implemented by AVX512 before. We know > > > > > that > > > > md5 can only be calculated serially for an object, and cannot be > > > > split for concurrent calculation. For AVX512, its basic > > > > understanding is to divide a core into 16 lanes, and then these 16 > > > > lanes can be calculated at the same time. So when we use md5 > > > > implemented by AVX512, we need to wait for multiple request objects to > > calculate md5 at the same time. > > > > > > > > > > So here are two difficulties to consider: > > > > > 1. When calculating, we need to fill all the lanes on a core as > > > > > much as > > > possible. > > > > Only in this way can the advantages of AVX512/AVX2 be reflected. > > > > > 2. What we have seen so far is the comparison between using > > > > > AVX512/AVX2 > > > > on a single core and not using it. But when we actually run RGW, > > > > unless RGW is allocated or the machine where it is located is > > > > already running with 100% CPU, then using AVX512 will increase the > > > > calculation speed of md5. But when less than 100% CPU is running, > > > > using AVX512 to save core may cause slowdown. So how do we know > > > > under what circumstances we should use AVX instructions in code? > > > > > > > > well put, this is the part i'm struggling with too. it feels like a > > > > tradeoff between cpu usage and added latency (both from thread > > > > synchronization and waiting for full batches) > > > > > > > > if we could track the rate of hash updates per second, we might use > > > > that to decide whether we're likely to get a full batch within some > > > > limit of acceptable latency > > > > > > > > RGWPutObj could probably mask some of this latency by running these > > > > asynchronous hashes in parallel while reading the next 4MB chunk > > > > from the frontend > > > > > > > > in https://github.com/ceph/ceph/pull/52385 i introduced the concept > > > > of a batch_timeout, which can force the processing of a partial batch. > > > > bounding this latency seemed like a necessary part of the model. if > > > > RGWPutObj can mask this latency, then we might use that > > > > batch_timeout to avoid the need to track a global hash rate > > > > > > > > > > > > > > We have implemented a POC before, using QAT to implement the hash > > > > > algorithm in ceph (SHA256, MD5, SHA1, SHA512, HMACSHA256, > > > > > HMACSHA1), > > > > > > > > very cool, thanks. what is the benefit of QAT here, compared to > > > > something like isa-l_crypto that just uses AVX instructions? is QAT > > > > able to > > > offload some of this? > > > > would the use of QAT rule out any hardware (like AMD cpus) that > > > > would otherwise support AVX? > > > > > > > > > However, due to md5 security reasons and there is no convenient > > > > > alternative > > > > framework in ceph, it is temporarily blocked. > > > > > > > https://github.com/ceph/ceph/compare/main...hualongfeng:ceph:hash_ > > > > > qa > > > > > t_ > > > > > mode > > > > > > > > i'll reach out to our security contact to get some more clarity on > > > > this stuff. i know that openssl's FIPS certification is important to > > > > downstream products. but > > > > md5 isn't a cryptographic hash and etag isn't used for security, so > > > > i've assumed we could use other md5 implementations there. i'm less > > > > sure about the SHA family, but i know Matt's interested in using > > > > those for checksumming in rgw > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > -Hualong > > > > > > > > > > > -----Original Message----- > > > > > > From: Casey Bodley <cbodley(a)redhat.com> > > > > > > Sent: Tuesday, July 11, 2023 11:06 PM > > > > > > To: Feng, Hualong <hualong.feng(a)intel.com> > > > > > > Subject: rgw: interest in isa-l_crypto for md5 acceleration > > > > > > > > > > > > hey Hualong, > > > > > > > > > > > > ceph is already using intel's isa-l_crypto library for crypto > > > > > > acceleration. i just started looking into its multi-buffer md5 > > > > > > implementation > > > > > > (https://github.com/intel/isa-l_crypto/blob/master/include/md5_mb. > > > > > > h) for use in rgw to vectorize our ETag calculations (a feature > > > > > > tracked in https://tracker.ceph.com/issues/61646). i've started > > > > > > some initial work in https://github.com/ceph/ceph/pull/52385, > > > > > > but we'll still need to decide how best to integrate that into > > > > > > rgw > > > > > > > > > > > > would your team be interested in collaborrating on this? we'd > > > > > > love your input on the design for rgw, and how best to measure > > > > > > and tune its performance > > > > > >

8 months, 3 weeks

2
1
0 0

question about concurrent cross directory rename?

by songmuhan＠stu.pku.edu.cn

I apologize for any inconvenience, but I have encountered a challenging situation while analyzing the Ceph filesystem's behavior during concurrent rename operations across directories. Specifically, my concern revolves around the potential for directory loops when two clients initiate renames simultaneously. In the VFS, there's a filesystem-specific vfs_rename_mutex that serializes the rename operation. In Ceph, I noticed the presence of a global client lock. However, I'm uncertain if the MDS serializes rename requests. Consider the following scenario: a / \ b c / \ d e / \ f g If Client 1 attempts to rename "c" to "f" while Client 2 tries to rename "b" to "g" concurrently, and both succeed, we could end up with a loop in the directory structure. Could you please provide clarity on how CephFS handles such situations? Your insights would be invaluable.

8 months, 3 weeks

2
1
0 0

v18.2.0 Reef released

by Yuri Weinstein

We're very happy to announce the first stable release of the Reef series. We express our gratitude to all members of the Ceph community who contributed by proposing pull requests, testing this release, providing feedback, and offering valuable suggestions. Major Changes from Quincy: - RADOS: RocksDB has been upgraded to version 7.9.2. - RADOS: There have been significant improvements to RocksDB iteration overhead and performance. - RADOS: The perf dump and perf schema commands have been deprecated in favor of the new counter dump and counter schema commands. - RADOS: Cache tiering is now deprecated. - RADOS: A new feature, the "read balancer", is now available, which allows users to balance primary PGs per pool on their clusters. - RGW: Bucket resharding is now supported for multi-site configurations. - RGW: There have been significant improvements to the stability and consistency of multi-site replication. - RGW: Compression is now supported for objects uploaded with Server-Side Encryption. - Dashboard: There is a new Dashboard page with improved layout. Active alerts and some important charts are now displayed inside cards. - RBD: Support for layered client-side encryption has been added. - Telemetry: Users can now opt in to participate in a leaderboard in the telemetry public dashboards. We encourage you to read the full release notes at https://ceph.io/en/news/blog/2023/v18-2-0-reef-released/ Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at https://download.ceph.com/tarballs/ceph-18.2.0.tar.gz * Containers at https://quay.io/repository/ceph/ceph * For packages, see https://docs.ceph.com/docs/master/install/get-packages/ * Release git sha1: 5dd24139a1eada541a3bc16b6941c5dde975e26d Did you know? Every Ceph release is built and tested on resources funded directly by the non-profit Ceph Foundation. If you would like to support this and our other efforts, please consider joining now https://ceph.io/en/foundation/.

8 months, 3 weeks

3
2
0 0

Contributor Credits for Reef 18.2.0

by Casey Bodley

Now that the Reef release is out, it's a good time to look back and celebrate our achievements. The Ceph project continues to grow and evolve thanks to the hard work of this wonderful community. Below you'll find some stats about the contributions during the Reef release cycle, sorted both by individual and organization. These were generated by src/script/credits.sh. Number of lines added and removed, by authors 1 43533 Zac Dover <zac.dover(a)proton.me> 2 35053 Yingxin Cheng <yingxin.cheng(a)intel.com> 3 27791 Casey Bodley <cbodley(a)redhat.com> 4 27252 Kaleb S. Keithley <kkeithle(a)redhat.com> 5 25288 Nitzan Mordechai <nmordech(a)redhat.com> 6 19261 Myoungwon Oh <myoungwon.oh(a)samsung.com> 7 18201 Xuehan Xu <xuxuehan(a)qianxin.com> 8 16167 Arthur Outhenin-Chalandre <arthur.outhenin-chalandre(a)cern.ch> 9 14744 Daniel Gryniewicz <dang(a)redhat.com> 10 14448 Yuval Lifshitz <ylifshit(a)redhat.com> 11 14332 Adam C. Emerson <aemerson(a)redhat.com> 12 13005 Samuel Just <sjust(a)redhat.com> 13 12664 Ronen Friedman <rfriedma(a)redhat.com> 14 11809 Radoslaw Zarzynski <rzarzynski(a)redhat.com> 15 10791 Matt Benjamin <mbenjamin(a)redhat.com> 16 10051 Ilya Dryomov <idryomov(a)redhat.com> 17 9756 Pere Diaz Bou <pdiazbou(a)redhat.com> 18 8795 Nizamudeen A <nia(a)redhat.com> 19 8716 Adam King <adking(a)redhat.com> 20 7752 Redouane Kachach <rkachach(a)redhat.com> 21 7598 David Galloway <dgallowa(a)redhat.com> 22 7363 Liu-Chunmei <chunmei.liu(a)intel.com> 23 6853 Matan Breizman <mbreizma(a)redhat.com> 24 6117 Kefu Chai <kchai(a)redhat.com> 25 6029 John Mulligan <jmulligan(a)redhat.com> 26 5107 Soumya Koduri <skoduri(a)redhat.com> 27 4895 J. Eric Ivancich <ivancich(a)redhat.com> 28 4795 Andriy Tkachuk <andriy.tkachuk(a)seagate.com> 29 4712 Xiubo Li <xiubli(a)redhat.com> 30 4529 Igor Fedotov <igor.fedotov(a)croit.io> 31 4045 Guillaume Abrioux <gabrioux(a)ibm.com> 32 3902 Or Ozeri <oro(a)il.ibm.com> 33 3892 Dhairya Parmar <dparmar(a)redhat.com> 34 3884 Shilpa Jagannath <smanjara(a)redhat.com> 35 3871 Avan Thakkar <athakkar(a)redhat.com> 36 3717 Sridhar Seshasayee <sseshasa(a)redhat.com> 37 3697 Aashish Sharma <aasharma(a)redhat.com> 38 3692 Zuhair AlSader <zuhair.alsader(a)seagate.com> 39 3648 Pritha Srivastava <prsrivas(a)redhat.com> 40 3590 Patrick Donnelly <pdonnell(a)redhat.com> 41 3484 Zhang Song <zhangsong325(a)gmail.com> 42 2715 Nikhilkumar Shelke <nshelke(a)redhat.com> 43 2688 Aswin Toni <aswin.toni(a)cern.ch> 44 2641 Lucian Petrut <lpetrut(a)cloudbasesolutions.com> 45 2546 Kotresh Hiremath Ravishankar <khiremat(a)redhat.com> 46 2239 Bryan Montalvan <bmontalv(a)redhat.com> 47 2107 Rishabh Dave <ridave(a)redhat.com> 48 2095 Laura Flores <lflores(a)ibm.com> 49 2042 Pedro Gonzalez Gomez <pegonzal(a)redhat.com> 50 2041 Neeraj Pratap Singh <Neeraj.Pratap.Singh1(a)ibm.com> 51 2028 Jonas Pfefferle <jpf(a)ibm.com> 52 1944 Cory Snyder <csnyder(a)1111systems.com> 53 1921 Abhishek Lekshmanan <abhishek.lekshmanan(a)cern.ch> 54 1906 Venky Shankar <vshankar(a)redhat.com> 55 1832 Anthony D Atri <anthony.datri(a)gmail.com> 56 1713 Yuri Weinstein <yuriw(a)redhat.com> 57 1661 Marcus Watts <mwatts(a)redhat.com> 58 1624 Jos Collin <jcollin(a)redhat.com> 59 1617 Ali Maredia <amaredia(a)redhat.com> 60 1514 Milind Changire <mchangir(a)redhat.com> 61 1473 Ngwa Sedrick Meh <nsedrick101(a)gmail.com> 62 1396 Steve Kowalik <steven(a)wedontsleep.org> 63 1362 Josh Salomon <jsalomon(a)redhat.com> 64 1324 Stefan Chivu <schivu(a)cloudbasesolutions.com> 65 1267 Gabriel BenHanokh <gbenhano(a)redhat.com> 66 1184 Yin Congmin <congmin.yin(a)intel.com> 67 1175 Ionut Balutoiu <ibalutoiu(a)cloudbasesolutions.com> 68 1130 Ramana Raja <rraja(a)redhat.com> 69 1108 Omri Zeneva <ozeneva(a)redhat.com> 70 1101 Paul Cuzner <pcuzner(a)ibm.com> 71 1089 Martin Ohmacht <mohmacht(a)us.ibm.com> 72 1043 Tobias Urdin <tobias.urdin(a)binero.se> 73 1037 Esmaeil Mirvakili <smirvaki(a)ucsc.edu> 74 1010 Adam Kupczyk <akupczyk(a)ibm.com> 75 994 Kamoltat Sirivadhna <ksirivad(a)redhat.com> 76 922 Sarthak Gupta <sargupta(a)redhat.com> 77 915 Ernesto Puerta <epuertat(a)redhat.com> 78 899 Xinyu Huang <xinyu.huang(a)intel.com> 79 845 Michael Fritch <mfritch(a)suse.com> 80 825 Sage Weil <sweil(a)redhat.com> 81 822 Greg Farnum <gfarnum(a)redhat.com> 82 784 Aravind Ramesh <Aravind.Ramesh(a)wdc.com> 83 701 JinyongHa <jy200.ha(a)samsung.com> 84 670 Josh Durgin <jdurgin(a)redhat.com> 85 665 Faith <faithuniterh(a)tutanota.com> 86 648 Shen, Hang <shenhang(a)kuaishou.com> 87 639 Mykola Golub <mykola.golub(a)clyso.com> 88 638 Gal Salomon <gsalomon(a)redhat.com> 89 629 Francesco Pantano <fpantano(a)redhat.com> 90 618 Michael J. Kidd <linuxkidd(a)redhat.com> 91 598 Waad Alkhoury <walkhour(a)redhat.com> 92 593 Vallari Agrawal <val.agl002(a)gmail.com> 93 518 Christopher Hoffman <choffman(a)redhat.com> 94 507 Prashant D <pdhange(a)redhat.com> 95 485 Zack Cerza <zack(a)redhat.com> 96 481 Jeff Layton <jlayton(a)redhat.com> 97 465 Iqbal Khan <iqkhan(a)redhat.com> 98 421 Josh Soref <2119212+jsoref(a)users.noreply.github.com> 99 409 Melissa Li <melissali(a)redhat.com> 100 368 Rafael Lopez <rafael.lopez(a)softiron.com> 101 366 Prasanna Kumar Kalever <prasanna.kalever(a)redhat.com> 102 336 Benoît Knecht <bknecht(a)protonmail.ch> 103 335 Miaomiao Liu <miaomiao.liu(a)intel.com> 104 333 Tatjana Dehler <tdehler(a)suse.com> 105 329 Wei Wang <lightmelodies(a)outlook.com> 106 325 Yongseok Oh <yongseok.oh(a)linecorp.com> 107 322 luo rixin <luorixin(a)huawei.com> 108 313 胡玮文 <sehuww(a)mail.scut.edu.cn> 109 310 Ziye Yang <ziye.yang(a)intel.com> 110 295 Tim Serong <tserong(a)suse.com> 111 281 Feng Hualong <hualong.feng(a)intel.com> 112 277 Ville Ojamo <14869000+bluikko(a)users.noreply.github.com> 113 275 Aishwarya Mathuria <amathuri(a)redhat.com> 114 270 Zhansong Gao <zhsgao(a)hotmail.com> 115 265 Deepika Upadhyay <dupadhya(a)redhat.com> 116 260 Yixin Jin <yjin(a)akamai.com> 117 250 Luis Domingues <domingues.luis(a)protonmail.ch> 118 246 Priya Sehgal <priya.sehgal(a)flipkart.com> 119 246 Neha Ojha <nojha(a)redhat.com> 120 245 Sungmin Lee <ssdohammer(a)gmail.com> 121 235 Josef Johansson <josef(a)oderland.se> 122 210 Jeet Jain <jeet.jain(a)seagate.com> 123 196 Xavi Garcia <xavi.garcia(a)suse.com> 124 190 Yaarit Hatuka <yaarit(a)redhat.com> 125 188 Joseph Sawaya <jsawaya(a)redhat.com> 126 185 haoyixing <haoyixing(a)kuaishou.com> 127 177 Brad Hubbard <bhubbard(a)redhat.com> 128 175 Dai Zhi Wei <daizhiwei3(a)huawei.com> 129 173 Conrad Hoffmann <ch(a)bitfehler.net> 130 169 Divyansh Kamboj <dkamboj(a)redhat.com> 131 155 Frank Ederveen <frank.ederveen(a)gmail.com> 132 148 Sumedh Anantrao Kulkarni <sumedh.a.kulkarni(a)seagate.com> 133 146 Ken Dreyer <kdreyer(a)redhat.com> 134 144 Deepak Mahale <deepak.mahale(a)seagate.com> 135 142 Patrick Seidensal <pseidensal(a)suse.com> 136 141 Mark Nelson <mark.nelson(a)clyso.com> 137 131 Mingyuan Liang <liangmingyuan(a)baidu.com> 138 130 Rongqi Sun <sunrongqi(a)huawei.com> 139 129 Volker Theile <vtheile(a)suse.com> 140 127 Mark Kogan <mkogan(a)redhat.com> 141 125 Sebastian Wagner <swagner(a)redhat.com> 142 119 Juan Miguel Olmo Martínez <jolmomar(a)redhat.com> 143 110 Chunsong Feng <fengchunsong(a)huawei.com> 144 104 Kellen Renshaw <kellen.renshaw(a)canonical.com> 145 102 Liav Turkia <liav.turkia(a)gmail.com> 146 99 Vicente Cheng <vicente_cheng(a)bigtera.com> 147 94 Tongliang Deng <dengtongliang(a)gmail.com> 148 94 ethanwu <ethanwu(a)synology.com> 149 91 Kalpesh Pandya <kapandya(a)redhat.com> 150 85 Teoman Onay <tonay(a)redhat.com> 151 82 Yehuda Sadeh <ysadehwe(a)redhat.com> 152 82 Sanal Kaarthikeyan <sanal.kaarthikeyan(a)seagate.com> 153 82 Dattaprasad Govekar <dattaprasad.govekar(a)seagate.com> 154 78 jinhong.kim <jinhong.kim0(a)navercorp.com> 155 76 Manuel Lausch <manuel.lausch(a)1und1.de> 156 76 Diwakar92 <diwakar.kumar(a)seagate.com> 157 75 Dan van der Ster <daniel.vanderster(a)cern.ch> 158 71 Huy Nguyen <huynp1999(a)gmail.com> 159 71 Cole Mitchell <cole.mitchell.ceph(a)gmail.com> 160 70 Selvakumar <selva.k.nambi(a)seagate.com> 161 68 Huber-ming <zhangsm01(a)inspur.com> 162 68 Francesco Torchia <francesco.torchia(a)suse.com> 163 66 Zhikuo Du <duzhk(a)qq.com> 164 62 Luís Henriques <lhenriques(a)suse.com> 165 61 Lei Cao <cao.leilc(a)inspur.com> 166 60 Xinyu Wang <wangxinyu(a)inspur.com> 167 60 Jiffin Tony Thottan <jthottan(a)redhat.com> 168 56 Jan Sobczak <jsobczak(a)cloudferro.com> 169 55 lichaochao <lichaochao2_yewu(a)cmss.chinamobile.com> 170 54 Lukas Mayer <lmayer(a)wind.gmbh> 171 53 Shreyansh Sancheti <ssanchet(a)redhat.com> 172 51 Yunqing Wang <wangyunqing(a)inspur.com> 173 51 Moritz Röhrich <moritz.rohrich(a)suse.com> 174 51 Mike Perez <miperez(a)redhat.com> 175 51 Christian Kugler <syphdias+git(a)gmail.com> 176 50 Alfonso Martínez <almartin(a)redhat.com> 177 48 Saurabh Jain <saurabh.jain2(a)seagate.com> 178 47 Kyle McGough <kmcgough(a)digitalocean.com> 179 46 Parayya Vastrad <parayya.vastrad(a)seagate.com> 180 41 Joshua Baergen <jbaergen(a)digitalocean.com> 181 40 Piotr Parczewski <piotr(a)stackhpc.com> 182 40 Alex Wojno <awojno(a)bloomberg.net> 183 39 zealot <xzd16(a)sohu.com> 184 39 Aliaksei Makarau <aliaksei.makarau(a)ibm.com> 185 38 Tom Coldrick <tcoldrick(a)bloomberg.net> 186 38 Tobias Bossert <tobias.bossert(a)fastpath.ch> 187 37 Shun Song <song.shun3(a)zte.com.cn> 188 36 Yingbin Wang <wangyingbin(a)inspur.com> 189 32 Ceph Release Team <ceph-maintainers(a)ceph.io> 190 31 Anton Turetckii <tyrchenok(a)gmail.com> 191 30 Sunny Kumar <sunkumar(a)redhat.com> 192 27 wanwencong <wanwc(a)chinatelecom.cn> 193 27 Seena Fallah <seenafallah(a)gmail.com> 194 27 Eneko Lacunza <elacunza(a)binovo.es> 195 26 Yite Gu <ess_gyt(a)qq.com> 196 25 dharmendra-jyani <dharmendra.jyani(a)seagate.com> 197 24 Justin Caratzas <jcaratza(a)redhat.com> 198 23 Salar Nosrati-Ershad <salar.nosratiershad(a)sotoon.ir> 199 23 Lorenz Bausch <info(a)lorenzbausch.de> 200 23 liqiang <liqiang64(a)huawei.com> 201 23 Alex Marangone <amarangone(a)digitalocean.com> 202 22 weixinwei <weixw3(a)lenovo.com> 203 21 Yang Honggang <yanghonggang(a)cmss.chinamobile.com> 204 20 Michael English <michael.english(a)seagate.com> 205 20 Gabriella S. Roman <gsroman(a)bu.edu> 206 19 Tan Changzhi <tancz1(a)lenovo.com> 207 18 Vrushal Chaudhari <vrushalcs(a)gmail.com> 208 17 Giuseppe Baccini <giuseppe.baccini(a)suse.com> 209 16 Or Friedmann <ofriedma(a)redhat.com> 210 16 Daniel Radjenovic <dradjenovic(a)digitalocean.com> 211 14 root <root(a)rhs-srv-14.storage-dev.lab.eng.bos.redhat.com> 212 14 Nithya Balachandran <nibalach(a)redhat.com> 213 14 Nikhil Kshirsagar <nikhil.kshirsagar(a)canonical.com> 214 14 Ankush Behl <cloudbehl(a)gmail.com> 215 14 Alex Handy <thinko(a)redhat.com> 216 13 Zhipeng Li <qiuxinyidian(a)gmail.com> 217 13 Thomas Anderson <me(a)thomasanderson.cloud> 218 13 Nathan Cutler <ncutler(a)suse.com> 219 12 Xiaoliang Yang <yangxiaoliang07(a)163.com> 220 12 Travis Nielsen <tnielsen(a)redhat.com> 221 12 Daniel Persson <mailto.woden(a)gmail.com> 222 11 Zhiming Zhang <zhangzhm1(a)chinatelecom.cn> 223 11 Satoru Takeuchi <satoru.takeuchi(a)gmail.com> 224 11 Patrick C. F. Ernzer <pcfe(a)pcfe.net> 225 11 Duncan Bellamy <dunk(a)denkimushi.com> 226 10 Yuli Yang <yuliyang(a)cmss.chinamobile.com> 227 10 Mer Xuanyi <xuanyi.meng(a)xtaotech.com> 228 10 Mathew Utter <mat(a)hazmat.dev> 229 10 Jianxin Li <jianxin1.li(a)intel.com> 230 10 Christoph Glaubitz <c.glaubitz(a)syseleven.de> 231 10 Cai Shan <caishan1993(a)foxmail.com> 232 9 Tamar Shacked <tshacked(a)redhat.com> 233 9 Marcio Roberto Starke <mrstarke(a)gmail.com> 234 9 Luciano Lo Giudice <luciano.logiudice(a)canonical.com> 235 8 Vikhyat Umrao <vikhyat(a)redhat.com> 236 8 Uli Fahrer <github(a)uli-fahrer.de> 237 8 Tengfei Wang <wangtengfei(a)inspur.com> 238 8 Qinfei Liu <lucas.liuqinfei(a)huawei.com> 239 8 Ponnuvel Palaniyappan <pponnuvel(a)gmail.com> 240 8 Matthew Taylor <matthew.taylor(a)digitalpacific.com.au> 241 8 Mary Frances <mhull(a)redhat.com> 242 8 krambrod <114069812+krambrod(a)users.noreply.github.com> 243 8 Henry Hirsch <henry.hirsch(a)1und1.de> 244 8 Hao Wang <wanghao72(a)baidu.com> 245 8 Franciszek Stachura <fbstachura(a)gmail.com> 246 8 Brad Fitzpatrick <brad(a)danga.com> 247 7 Weinan Gao <gaoweinan(a)inspur.com> 248 7 Michal Nasiadka <mnasiadka(a)gmail.com> 249 6 Vonesha Frost <voneshafrost(a)gmail.com> 250 6 Vedansh Bhartia <vedanshbhartia(a)gmail.com> 251 6 Konstantin Shalygin <k0ste(a)k0ste.ru> 252 6 Heðin Ejdesgaard <hej(a)ejdesgaard.fo> 253 5 Shasha Lu <lu.shasha(a)aishu.cn> 254 5 Robin H. Johnson <rjohnson(a)digitalocean.com> 255 5 Burt Holzman <burt(a)fnal.gov> 256 4 郑小剑 <zhengxj(a)bingosoft.net> 257 4 Shriya Deshmukh <shriya.deshmukh(a)seagate.com> 258 4 Sébastien Han <shan(a)redhat.com> 259 4 Richael Zhuang <richael.zhuang(a)arm.com> 260 4 Ranjini Mandyam Narasiodeyar <rmandyam(a)rmandyam.remote.csb> 261 4 Liu Yang <yippeetry(a)gmail.com> 262 4 Laurent Barbe <laurent(a)ksperis.com> 263 4 Johannes Liebl <68052021+jliebl-git(a)users.noreply.github.com> 264 4 jindengke <jindengke(a)inspur.com> 265 4 gengjichao <gengjichao(a)jd.com> 266 4 Ganesh Mahalingam <ganesh.mahalingam(a)intel.com> 267 4 Francisco J. Solis <siscomagma(a)gmail.com> 268 4 Dongsheng Yang <dongsheng.yang.linux(a)gmail.com> 269 4 Annabel Li <li3317(a)purdue.edu> 270 4 Amnon Hanuhov <AmnonSWE(a)gmail.com> 271 3 Yunfei Guan <yunfei.guan(a)xtaotech.com> 272 3 Tao <i237731947(a)outlook.com> 273 3 Sheng Qiu <herbert1984106(a)gmail.com> 274 3 Scott Shambarger <devel(a)shambarger.net> 275 3 Ondrej Mosnacek <omosnace(a)redhat.com> 276 3 Niklas Hambüchen <mail(a)nh2.me> 277 3 Malte Janduda <mail(a)janduda.net> 278 3 Lei Zhang <1091517373(a)qq.com> 279 3 Fei Wang <wf.ab(a)126.com> 280 2 Wong Hoi Sing Edison <hswong3i(a)pantarei-design.com> 281 2 Steven Hua <stevenhua(a)tencent.com> 282 2 Shu Yu <yushu20171007(a)163.com> 283 2 Shankar Malik <98207888+evershalik(a)users.noreply.github.com> 284 2 Sainithin Artham <sai.artham.19cse(a)bmu.edu.in> 285 2 Sachin Punadikar <sachin.punadikar(a)seagate.com> 286 2 root <root(a)ssc-vm-rhev4-2955.colo.seagate.com> 287 2 Pierre Riteau <pierre(a)stackhpc.com> 288 2 Parth Arora <paarora(a)redhat.com> 289 2 Mohan Sharma <mohan7427(a)gmail.com> 290 2 Mohammad Fatemipour <mohammad.fatemipour(a)sotoon.ir> 291 2 Michaela Lang <milang(a)redhat.com> 292 2 Kyujin Cho <bori19960(a)snu.ac.kr> 293 2 Koen Kooi <koen(a)softiron.com> 294 2 Kenneth Van Alstyne <Kenny.VanAlstyne(a)softiron.com> 295 2 Kai Hollberg <kai.hollberg(a)googlemail.com> 296 2 Judah van der Ster <jevanderster(a)gmail.com> 297 2 João Eduardo Luís <joao(a)suse.de> 298 2 Jianwei Zhang <jianwei1216(a)qq.com> 299 2 James Mcclune <jmcclune(a)mcclunetechnologies.net> 300 2 James Lakin <james(a)jameslakin.co.uk> 301 2 Jaehoon Shim <mattjs(a)snu.ac.kr> 302 2 Guido Santella <gsantella(a)southhills.edu> 303 2 Eunice Lee <eunl(a)microsoft.com> 304 2 Chen Yuanrun <chen-yuanrun(a)foxmail.com> 305 2 Ben Gao <bengao168(a)msn.com> 306 2 Andreas Teuchert <a.teuchert(a)syseleven.de> 307 2 Alex Ponomarev <alex.ponomarev(a)phystech.edu> 308 2 Alexander Proschek <alexander.proschek(a)protonmail.com> 309 2 Aggelos Toumasis <toumasis.aggelos(a)gmail.com> 310 2 Aaryan Porwal <aaryanporwal2233(a)gmail.com> 311 1 Sam James <sam(a)gentoo.org> 312 1 Pete Zaitcev <zaitcev(a)redhat.com> 313 1 James Page <james.page(a)ubuntu.com> 314 0 dependabot[bot] <49699333+dependabot[bot](a)users.noreply.github.com> Number of lines added and removed, by organization 1 333821 Red Hat <contact(a)redhat.com> 2 45439 Intel <contact(a)intel.com> 3 43533 Ceph Foundation <membership(a)linuxfoundation.org> 4 19962 Samsung <contact(a)samsung.com> 5 18934 CERN <contact(a)cern.ch> 6 18201 Qianxin <contact(a)qianxin.com> 7 12648 Unaffiliated <no(a)organization.net> 8 9446 Seagate Technology <contact(a)seagate.com> 9 8445 IBM <contact(a)IBM.com> 10 8071 SUSE <contact(a)suse.com> 11 5140 Cloudbase Solutions <contact(a)cloudbasesolutions.com> 12 1969 Croit <contact(a)croit.io> 13 1944 11:11 Systems <contact(a)1111systems.com> 14 1037 University of California, Santa Cruz <contact(a)cs.ucsc.edu> 15 833 KuaiShou <contact(a)kuaishou.com> 16 784 Western Digital Corporation <contact(a)westerndigital.com> 17 768 Huawei <contact(a)huawei.com> 18 602 Clyso GmbH <contact(a)clyso.com> 19 372 SoftIron <contact(a)softiron.co.uk> 20 325 Line Corporation <contact(a)linecorp.com> 21 313 South China University of Technology <contact(a)scut.edu.cn> 22 295 Inspur <contact(a)inspur.com> 23 260 Akamai Technologies <contact(a)akamai.com> 24 246 Flipkart <contact(a)flipkart.com> 25 139 Baidu <contact(a)baidu.com> 26 132 DigitalOcean <contact(a)digitalocean.com> 27 128 Canonical <contact(a)canonical.com> 28 99 Tencent <contact(a)tencent.com> 29 99 Bigtera <contact(a)bigtera.com> 30 94 Synology, Inc. <contact(a)synology.com> 31 86 China Mobile <contact(a)chinamobile.com> 32 84 1&1 AG <contact(a)1und1.ag> 33 80 Koor Technologies, Inc. <contact(a)koor.tech> 34 78 Naver <contact(a)navercorp.com> 35 78 Bloomberg <opensource(a)bloomberg.net> 36 56 CloudFerro <contact(a)cloudferro.com> 37 49 StackHPC <contact(a)stackhpc.com> 38 41 Lenovo <contact(a)lenovo.com> 39 39 Sohu, Inc. <contact(a)sohu.com> 40 38 China Telecom <contact(a)chinatelecom.com> 41 37 ZTE <contact(a)zte.com.cn> 42 32 Ceph Release Team <ceph-maintainers(a)ceph.io> 43 27 Cafe Bazaar <info(a)cafebazaar.ir> 44 27 Binovo <contact(a)binovo.es> 45 20 Boston University <contact(a)bu.edu> 46 13 XTao Co. Ltd. <contact(a)xtaotech.com> 47 12 SysEleven <info(a)syseleven.de> 48 8 Digital Pacific <contact(a)digitalpacific.com.au> 49 5 Fermi National Accelerator Laboratory <fermilab(a)fnal.gov> 50 4 Purdue University <contact(a)purdue.edu> 51 4 Eayun <contact(a)eayun.com> 52 4 CCM Benchmark <contact(a)ccmbenchmark.com> 53 4 ARM <contact(a)arm.com> 54 2 Microsoft Corporation <contact(a)microsoft.com> 55 2 McClune Technologies <contact(a)mcclunetechnologies.net> 56 1 Gentoo <contact(a)gentoo.org> Commits, by authors 1 395 Zac Dover <zac.dover(a)proton.me> 2 373 Casey Bodley <cbodley(a)redhat.com> 3 288 Yingxin Cheng <yingxin.cheng(a)intel.com> 4 261 Radoslaw Zarzynski <rzarzynski(a)redhat.com> 5 260 Kefu Chai <kchai(a)redhat.com> 6 176 Ilya Dryomov <idryomov(a)redhat.com> 7 170 Samuel Just <sjust(a)redhat.com> 8 162 Adam King <adking(a)redhat.com> 9 150 Matan Breizman <mbreizma(a)redhat.com> 10 136 Myoungwon Oh <myoungwon.oh(a)samsung.com> 11 136 John Mulligan <jmulligan(a)redhat.com> 12 130 Xiubo Li <xiubli(a)redhat.com> 13 127 Xuehan Xu <xuxuehan(a)qianxin.com> 14 121 Adam C. Emerson <aemerson(a)redhat.com> 15 111 Patrick Donnelly <pdonnell(a)redhat.com> 16 103 Redouane Kachach <rkachach(a)redhat.com> 17 103 Nizamudeen A <nia(a)redhat.com> 18 79 Guillaume Abrioux <gabrioux(a)ibm.com> 19 75 Rishabh Dave <ridave(a)redhat.com> 20 74 Chunmei Liu <chunmei.liu(a)intel.com> 21 72 Dhairya Parmar <dparmar(a)redhat.com> 22 68 Pere Diaz Bou <pdiazbou(a)redhat.com> 23 65 Laura Flores <lflores(a)ibm.com> 24 60 Ronen Friedman <rfriedma(a)redhat.com> 25 59 Igor Fedotov <igor.fedotov(a)croit.io> 26 56 Yuval Lifshitz <ylifshit(a)redhat.com> 27 54 Matt Benjamin <mbenjamin(a)redhat.com> 28 53 Shilpa Jagannath <smanjara(a)redhat.com> 29 50 Lucian Petrut <lpetrut(a)cloudbasesolutions.com> 30 48 Kotresh Hiremath Ravishankar <khiremat(a)redhat.com> 31 47 Venky Shankar <vshankar(a)redhat.com> 32 47 Nitzan Mordechai <nmordech(a)redhat.com> 33 44 Zhang Song <zhangsong325(a)gmail.com> 34 44 J. Eric Ivancich <ivancich(a)redhat.com> 35 40 Soumya Koduri <skoduri(a)redhat.com> 36 40 Neeraj Pratap Singh <Neeraj.Pratap.Singh1(a)ibm.com> 37 40 Abhishek Lekshmanan <abhishek.lekshmanan(a)cern.ch> 38 38 Sridhar Seshasayee <sseshasa(a)redhat.com> 39 37 Aashish Sharma <aasharma(a)redhat.com> 40 35 Jos Collin <jcollin(a)redhat.com> 41 35 David Galloway <dgallowa(a)redhat.com> 42 35 Daniel Gryniewicz <dang(a)redhat.com> 43 35 Avan Thakkar <athakkar(a)redhat.com> 44 33 Michael Fritch <mfritch(a)suse.com> 45 32 Kamoltat Sirivadhna <ksirivad(a)redhat.com> 46 30 Tobias Urdin <tobias.urdin(a)binero.se> 47 30 Nikhilkumar Shelke <nshelke(a)redhat.com> 48 30 Ernesto Puerta <epuertat(a)redhat.com> 49 28 Milind Changire <mchangir(a)redhat.com> 50 28 Greg Farnum <gfarnum(a)redhat.com> 51 28 Anthony D Atri <anthony.datri(a)gmail.com> 52 27 Cory Snyder <csnyder(a)1111systems.com> 53 26 Pritha Srivastava <prsrivas(a)redhat.com> 54 24 Sage Weil <sweil(a)redhat.com> 55 24 Ramana Raja <rraja(a)redhat.com> 56 23 Pedro Gonzalez Gomez <pegonzal(a)redhat.com> 57 23 Omri Zeneva <ozeneva(a)redhat.com> 58 22 Tim Serong <tserong(a)suse.com> 59 22 Neha Ojha <nojha(a)redhat.com> 60 22 Adam Kupczyk <akupczyk(a)ibm.com> 61 20 Or Ozeri <oro(a)il.ibm.com> 62 18 Yuri Weinstein <yuriw(a)redhat.com> 63 18 Mykola Golub <mykola.golub(a)clyso.com> 64 18 Marcus Watts <mwatts(a)redhat.com> 65 17 Sarthak Gupta <sargupta(a)redhat.com> 66 17 Ngwa Sedrick Meh <nsedrick101(a)gmail.com> 67 16 yuval Lifshitz <ylifshit(a)redhat.com> 68 16 Xinyu Huang <xinyu.huang(a)intel.com> 69 16 Ville Ojamo <14869000+bluikko(a)users.noreply.github.com> 70 16 Jeff Layton <jlayton(a)redhat.com> 71 16 Arthur Outhenin-Chalandre <arthur.outhenin-chalandre(a)cern.ch> 72 16 Aravind Ramesh <Aravind.Ramesh(a)wdc.com> 73 15 胡玮文 <sehuww(a)mail.scut.edu.cn> 74 15 Zack Cerza <zack(a)redhat.com> 75 15 Ken Dreyer <kdreyer(a)redhat.com> 76 15 Josh Durgin <jdurgin(a)redhat.com> 77 14 Yin Congmin <congmin.yin(a)intel.com> 78 14 Deepika Upadhyay <dupadhya(a)redhat.com> 79 14 Ali Maredia <amaredia(a)redhat.com> 80 13 Prashant D <pdhange(a)redhat.com> 81 13 Paul Cuzner <pcuzner(a)ibm.com> 82 13 luo rixin <luorixin(a)huawei.com> 83 12 Yaarit Hatuka <yaarit(a)redhat.com> 84 12 Lei Cao <cao.leilc(a)inspur.com> 85 11 Xinyu Wang <wangxinyu(a)inspur.com> 86 11 Tatjana Dehler <tdehler(a)suse.com> 87 11 Stefan Chivu <schivu(a)cloudbasesolutions.com> 88 11 Prasanna Kumar Kalever <prasanna.kalever(a)redhat.com> 89 10 Mark Kogan <mkogan(a)redhat.com> 90 10 Aishwarya Mathuria <amathuri(a)redhat.com> 91 9 Volker Theile <vtheile(a)suse.com> 92 9 Huber-ming <zhangsm01(a)inspur.com> 93 8 Rongqi Sun <sunrongqi(a)huawei.com> 94 8 Luis Domingues <domingues.luis(a)protonmail.ch> 95 8 Kaleb S. Keithley <kkeithle(a)redhat.com> 96 8 Dan van der Ster <daniel.vanderster(a)cern.ch> 97 7 Yunqing Wang <wangyunqing(a)inspur.com> 98 7 Mike Perez <miperez(a)redhat.com> 99 7 Mark Nelson <mark.nelson(a)clyso.com> 100 7 Gabriel BenHanokh <gbenhano(a)redhat.com> 101 7 dependabot[bot] <49699333+dependabot[bot](a)users.noreply.github.com> 102 7 Andriy Tkachuk <andriy.tkachuk(a)seagate.com> 103 6 Sumedh Anantrao Kulkarni <sumedh.a.kulkarni(a)seagate.com> 104 6 Shen, Hang <shenhang(a)kuaishou.com> 105 6 Melissa Li <melissali(a)redhat.com> 106 6 Josh Salomon <jsalomon(a)redhat.com> 107 6 Jonas Pfefferle <jpf(a)ibm.com> 108 6 Christopher Hoffman <choffman(a)redhat.com> 109 6 Benoît Knecht <bknecht(a)protonmail.ch> 110 5 Zhansong Gao <zhsgao(a)hotmail.com> 111 5 Yingbin Wang <wangyingbin(a)inspur.com> 112 5 Tongliang Deng <dengtongliang(a)gmail.com> 113 5 Sebastian Wagner <swagner(a)redhat.com> 114 5 Patrick Seidensal <pseidensal(a)suse.com> 115 5 Mingyuan Liang <liangmingyuan(a)baidu.com> 116 5 Miaomiao Liu <miaomiao.liu(a)intel.com> 117 5 Lorenz Bausch <info(a)lorenzbausch.de> 118 5 jinhong.kim <jinhong.kim0(a)navercorp.com> 119 5 Faith <faithuniterh(a)tutanota.com> 120 4 Zhiming Zhang <zhangzhm1(a)chinatelecom.cn> 121 4 Yixin Jin <yjin(a)akamai.com> 122 4 Yehuda Sadeh <ysadehwe(a)redhat.com> 123 4 Weinan Gao <gaoweinan(a)inspur.com> 124 4 Salar Nosrati-Ershad <salar.nosratiershad(a)sotoon.ir> 125 4 Piotr Parczewski <piotr(a)stackhpc.com> 126 4 Mer Xuanyi <xuanyi.meng(a)xtaotech.com> 127 4 Joshua Baergen <jbaergen(a)digitalocean.com> 128 4 Joseph Sawaya <jsawaya(a)redhat.com> 129 4 JinyongHa <jy200.ha(a)samsung.com> 130 4 haoyixing <haoyixing(a)kuaishou.com> 131 4 Ceph Release Team <ceph-maintainers(a)ceph.io> 132 4 Bryan Montalvan <bmontalv(a)redhat.com> 133 4 Brad Hubbard <bhubbard(a)redhat.com> 134 4 Aswin Toni <aswin.toni(a)cern.ch> 135 3 Ziye Yang <ziye.yang(a)intel.com> 136 3 Yongseok Oh <yongseok.oh(a)linecorp.com> 137 3 Yang Honggang <yanghonggang(a)cmss.chinamobile.com> 138 3 Wei Wang <lightmelodies(a)outlook.com> 139 3 Vikhyat Umrao <vikhyat(a)redhat.com> 140 3 Teoman Onay <tonay(a)redhat.com> 141 3 Sunny Kumar <sunkumar(a)redhat.com> 142 3 Steve Kowalik <steven(a)wedontsleep.org> 143 3 Shreyansh Sancheti <ssanchet(a)redhat.com> 144 3 Selvakumar <selva.k.nambi(a)seagate.com> 145 3 Moritz Röhrich <moritz.rohrich(a)suse.com> 146 3 Mary Frances <mhull(a)redhat.com> 147 3 Luís Henriques <lhenriques(a)suse.com> 148 3 liqiang <liqiang64(a)huawei.com> 149 3 lichaochao <lichaochao2_yewu(a)cmss.chinamobile.com> 150 3 Justin Caratzas <jcaratza(a)redhat.com> 151 3 Juan Miguel Olmo Martínez <jolmomar(a)redhat.com> 152 3 Josh Soref <2119212+jsoref(a)users.noreply.github.com> 153 3 Jeet Jain <jeet.jain(a)seagate.com> 154 3 Ionut Balutoiu <ibalutoiu(a)cloudbasesolutions.com> 155 3 Gal Salomon <gsalomon(a)redhat.com> 156 3 ethanwu <ethanwu(a)synology.com> 157 3 Eneko Lacunza <elacunza(a)binovo.es> 158 3 Duncan Bellamy <dunk(a)denkimushi.com> 159 2 Yuli Yang <yuliyang(a)cmss.chinamobile.com> 160 2 Vicente Cheng <vicente_cheng(a)bigtera.com> 161 2 Vallari Agrawal <val.agl002(a)gmail.com> 162 2 Thomas Anderson <me(a)thomasanderson.cloud> 163 2 Sungmin Lee <ssdohammer(a)gmail.com> 164 2 Seena Fallah <seenafallah(a)gmail.com> 165 2 Saurabh Jain <saurabh.jain2(a)seagate.com> 166 2 Satoru Takeuchi <satoru.takeuchi(a)gmail.com> 167 2 Sanal Kaarthikeyan <sanal.kaarthikeyan(a)seagate.com> 168 2 Richael Zhuang <richael.zhuang(a)arm.com> 169 2 Rafael Lopez <rafael.lopez(a)softiron.com> 170 2 Priya Sehgal <priya.sehgal(a)flipkart.com> 171 2 Nikhil Kshirsagar <nikhil.kshirsagar(a)canonical.com> 172 2 Michael J. Kidd <linuxkidd(a)redhat.com> 173 2 Michael English <michael.english(a)seagate.com> 174 2 Lukas Mayer <lmayer(a)wind.gmbh> 175 2 Laurent Barbe <laurent(a)ksperis.com> 176 2 Konstantin Shalygin <k0ste(a)k0ste.ru> 177 2 Jiffin Tony Thottan <jthottan(a)redhat.com> 178 2 Iqbal Khan <iqkhan(a)redhat.com> 179 2 Huy Nguyen <huynp1999(a)gmail.com> 180 2 Frank Ederveen <frank.ederveen(a)gmail.com> 181 2 Francesco Torchia <francesco.torchia(a)suse.com> 182 2 Francesco Pantano <fpantano(a)redhat.com> 183 2 Feng Hualong <hualong.feng(a)intel.com> 184 2 Esmaeil Mirvakili <smirvaki(a)ucsc.edu> 185 2 Diwakar92 <diwakar.kumar(a)seagate.com> 186 2 Divyansh Kamboj <dkamboj(a)redhat.com> 187 2 Deepak Mahale <deepak.mahale(a)seagate.com> 188 2 Dattaprasad Govekar <dattaprasad.govekar(a)seagate.com> 189 2 Daniel Persson <mailto.woden(a)gmail.com> 190 2 Dai Zhi Wei <daizhiwei3(a)huawei.com> 191 2 Cole Mitchell <cole.mitchell.ceph(a)gmail.com> 192 2 Cai Shan <caishan1993(a)foxmail.com> 193 2 Brad Fitzpatrick <brad(a)danga.com> 194 2 Aliaksei Makarau <aliaksei.makarau(a)ibm.com> 195 2 Alex Marangone <amarangone(a)digitalocean.com> 196 1 郑小剑 <zhengxj(a)bingosoft.net> 197 1 Zuhair AlSader <zuhair.alsader(a)seagate.com> 198 1 Zhipeng Li <qiuxinyidian(a)gmail.com> 199 1 Zhikuo Du <duzhk(a)qq.com> 200 1 zealot <xzd16(a)sohu.com> 201 1 Yunfei Guan <yunfei.guan(a)xtaotech.com> 202 1 Yite Gu <ess_gyt(a)qq.com> 203 1 Xiaoliang Yang <yangxiaoliang07(a)163.com> 204 1 Xavi Garcia <xavi.garcia(a)suse.com> 205 1 Wong Hoi Sing Edison <hswong3i(a)pantarei-design.com> 206 1 weixinwei <weixw3(a)lenovo.com> 207 1 wanwencong <wanwc(a)chinatelecom.cn> 208 1 Waad Alkhoury <walkhour(a)redhat.com> 209 1 Vrushal Chaudhari <vrushalcs(a)gmail.com> 210 1 Vonesha Frost <voneshafrost(a)gmail.com> 211 1 Vedansh Bhartia <vedanshbhartia(a)gmail.com> 212 1 Uli Fahrer <github(a)uli-fahrer.de> 213 1 Travis Nielsen <tnielsen(a)redhat.com> 214 1 Tom Coldrick <tcoldrick(a)bloomberg.net> 215 1 Tobias Bossert <tobias.bossert(a)fastpath.ch> 216 1 Tengfei Wang <wangtengfei(a)inspur.com> 217 1 Tao <i237731947(a)outlook.com> 218 1 Tan Changzhi <tancz1(a)lenovo.com> 219 1 Tamar Shacked <tshacked(a)redhat.com> 220 1 Steven Hua <stevenhua(a)tencent.com> 221 1 Shu Yu <yushu20171007(a)163.com> 222 1 Shun Song <song.shun3(a)zte.com.cn> 223 1 Shriya Deshmukh <shriya.deshmukh(a)seagate.com> 224 1 Sheng Qiu <herbert1984106(a)gmail.com> 225 1 Shasha Lu <lu.shasha(a)aishu.cn> 226 1 Shankar Malik <98207888+evershalik(a)users.noreply.github.com> 227 1 Sébastien Han <shan(a)redhat.com> 228 1 Scott Shambarger <devel(a)shambarger.net> 229 1 Sam James <sam(a)gentoo.org> 230 1 Sainithin Artham <sai.artham.19cse(a)bmu.edu.in> 231 1 Sachin Punadikar <sachin.punadikar(a)seagate.com> 232 1 root <root(a)ssc-vm-rhev4-2955.colo.seagate.com> 233 1 root <root(a)rhs-srv-14.storage-dev.lab.eng.bos.redhat.com> 234 1 Robin H. Johnson <rjohnson(a)digitalocean.com> 235 1 Ranjini Mandyam Narasiodeyar <rmandyam(a)rmandyam.remote.csb> 236 1 Qinfei Liu <lucas.liuqinfei(a)huawei.com> 237 1 Ponnuvel Palaniyappan <pponnuvel(a)gmail.com> 238 1 Pierre Riteau <pierre(a)stackhpc.com> 239 1 Pete Zaitcev <zaitcev(a)redhat.com> 240 1 Patrick C. F. Ernzer <pcfe(a)pcfe.net> 241 1 Parth Arora <paarora(a)redhat.com> 242 1 Parayya Vastrad <parayya.vastrad(a)seagate.com> 243 1 Or Friedmann <ofriedma(a)redhat.com> 244 1 Ondrej Mosnacek <omosnace(a)redhat.com> 245 1 Nithya Balachandran <nibalach(a)redhat.com> 246 1 Niklas Hambüchen <mail(a)nh2.me> 247 1 Nathan Cutler <ncutler(a)suse.com> 248 1 Mohan Sharma <mohan7427(a)gmail.com> 249 1 Mohammad Fatemipour <mohammad.fatemipour(a)sotoon.ir> 250 1 Michal Nasiadka <mnasiadka(a)gmail.com> 251 1 Michaela Lang <milang(a)redhat.com> 252 1 Matthew Taylor <matthew.taylor(a)digitalpacific.com.au> 253 1 Mathew Utter <mat(a)hazmat.dev> 254 1 Martin Ohmacht <mohmacht(a)us.ibm.com> 255 1 Marcio Roberto Starke <mrstarke(a)gmail.com> 256 1 Manuel Lausch <manuel.lausch(a)1und1.de> 257 1 Malte Janduda <mail(a)janduda.net> 258 1 Luciano Lo Giudice <luciano.logiudice(a)canonical.com> 259 1 Liu Yang <yippeetry(a)gmail.com> 260 1 Liav Turkia <liav.turkia(a)gmail.com> 261 1 Lei Zhang <1091517373(a)qq.com> 262 1 Kyujin Cho <bori19960(a)snu.ac.kr> 263 1 Kyle McGough <kmcgough(a)digitalocean.com> 264 1 krambrod <114069812+krambrod(a)users.noreply.github.com> 265 1 Koen Kooi <koen(a)softiron.com> 266 1 Kenneth Van Alstyne <Kenny.VanAlstyne(a)softiron.com> 267 1 Kellen Renshaw <kellen.renshaw(a)canonical.com> 268 1 Kalpesh Pandya <kapandya(a)redhat.com> 269 1 Kai Hollberg <kai.hollberg(a)googlemail.com> 270 1 Judah van der Ster <jevanderster(a)gmail.com> 271 1 Josef Johansson <josef(a)oderland.se> 272 1 Johannes Liebl <68052021+jliebl-git(a)users.noreply.github.com> 273 1 João Eduardo Luís <joao(a)suse.de> 274 1 jindengke <jindengke(a)inspur.com> 275 1 Jianxin Li <jianxin1.li(a)intel.com> 276 1 Jianwei Zhang <jianwei1216(a)qq.com> 277 1 Jan Sobczak <jsobczak(a)cloudferro.com> 278 1 James Page <james.page(a)ubuntu.com> 279 1 James Mcclune <jmcclune(a)mcclunetechnologies.net> 280 1 James Lakin <james(a)jameslakin.co.uk> 281 1 Jaehoon Shim <mattjs(a)snu.ac.kr> 282 1 Henry Hirsch <henry.hirsch(a)1und1.de> 283 1 Heðin Ejdesgaard <hej(a)ejdesgaard.fo> 284 1 Hao Wang <wanghao72(a)baidu.com> 285 1 Guido Santella <gsantella(a)southhills.edu> 286 1 Giuseppe Baccini <giuseppe.baccini(a)suse.com> 287 1 gengjichao <gengjichao(a)jd.com> 288 1 Ganesh Mahalingam <ganesh.mahalingam(a)intel.com> 289 1 Gabriella S. Roman <gsroman(a)bu.edu> 290 1 Franciszek Stachura <fbstachura(a)gmail.com> 291 1 Francisco J. Solis <siscomagma(a)gmail.com> 292 1 Fei Wang <wf.ab(a)126.com> 293 1 Eunice Lee <eunl(a)microsoft.com> 294 1 Dongsheng Yang <dongsheng.yang.linux(a)gmail.com> 295 1 dharmendra-jyani <dharmendra.jyani(a)seagate.com> 296 1 Daniel Radjenovic <dradjenovic(a)digitalocean.com> 297 1 Conrad Hoffmann <ch(a)bitfehler.net> 298 1 Chunsong Feng <fengchunsong(a)huawei.com> 299 1 Christoph Glaubitz <c.glaubitz(a)syseleven.de> 300 1 Christian Kugler <syphdias+git(a)gmail.com> 301 1 Chen Yuanrun <chen-yuanrun(a)foxmail.com> 302 1 Burt Holzman <burt(a)fnal.gov> 303 1 Ben Gao <bengao168(a)msn.com> 304 1 Anton Turetckii <tyrchenok(a)gmail.com> 305 1 Annabel Li <li3317(a)purdue.edu> 306 1 Ankush Behl <cloudbehl(a)gmail.com> 307 1 Andreas Teuchert <a.teuchert(a)syseleven.de> 308 1 Amnon Hanuhov <AmnonSWE(a)gmail.com> 309 1 Alfonso Martínez <almartin(a)redhat.com> 310 1 Alex Wojno <awojno(a)bloomberg.net> 311 1 Alex Ponomarev <alex.ponomarev(a)phystech.edu> 312 1 Alex Handy <thinko(a)redhat.com> 313 1 Alexander Proschek <alexander.proschek(a)protonmail.com> 314 1 Aggelos Toumasis <toumasis.aggelos(a)gmail.com> 315 1 Aaryan Porwal <aaryanporwal2233(a)gmail.com> Commits, by organizations 1 3948 Red Hat <contact(a)redhat.com> 2 404 Intel <contact(a)intel.com> 3 395 Ceph Foundation <membership(a)linuxfoundation.org> 4 266 Unaffiliated <no(a)organization.net> 5 165 SUSE <contact(a)suse.com> 6 140 Samsung <contact(a)samsung.com> 7 127 Qianxin <contact(a)qianxin.com> 8 64 Cloudbase Solutions <contact(a)cloudbasesolutions.com> 9 50 Inspur <contact(a)inspur.com> 10 50 IBM <contact(a)IBM.com> 11 37 Seagate Technology <contact(a)seagate.com> 12 35 Croit <contact(a)croit.io> 13 28 Huawei <contact(a)huawei.com> 14 28 CERN <contact(a)cern.ch> 15 27 11:11 Systems <contact(a)1111systems.com> 16 16 Western Digital Corporation <contact(a)westerndigital.com> 17 15 South China University of Technology <contact(a)scut.edu.cn> 18 14 Clyso GmbH <contact(a)clyso.com> 19 10 KuaiShou <contact(a)kuaishou.com> 20 9 DigitalOcean <contact(a)digitalocean.com> 21 8 China Mobile <contact(a)chinamobile.com> 22 6 StackHPC <contact(a)stackhpc.com> 23 6 Baidu <contact(a)baidu.com> 24 5 XTao Co. Ltd. <contact(a)xtaotech.com> 25 5 Tencent <contact(a)tencent.com> 26 5 Naver <contact(a)navercorp.com> 27 5 China Telecom <contact(a)chinatelecom.com> 28 5 Canonical <contact(a)canonical.com> 29 4 SoftIron <contact(a)softiron.co.uk> 30 4 Ceph Release Team <ceph-maintainers(a)ceph.io> 31 4 Akamai Technologies <contact(a)akamai.com> 32 3 Synology, Inc. <contact(a)synology.com> 33 3 Line Corporation <contact(a)linecorp.com> 34 3 Binovo <contact(a)binovo.es> 35 2 University of California, Santa Cruz <contact(a)cs.ucsc.edu> 36 2 SysEleven <info(a)syseleven.de> 37 2 Lenovo <contact(a)lenovo.com> 38 2 Koor Technologies, Inc. <contact(a)koor.tech> 39 2 Flipkart <contact(a)flipkart.com> 40 2 CCM Benchmark <contact(a)ccmbenchmark.com> 41 2 Cafe Bazaar <info(a)cafebazaar.ir> 42 2 Bloomberg <opensource(a)bloomberg.net> 43 2 Bigtera <contact(a)bigtera.com> 44 2 ARM <contact(a)arm.com> 45 2 1&1 AG <contact(a)1und1.ag> 46 1 ZTE <contact(a)zte.com.cn> 47 1 Sohu, Inc. <contact(a)sohu.com> 48 1 Purdue University <contact(a)purdue.edu> 49 1 Microsoft Corporation <contact(a)microsoft.com> 50 1 McClune Technologies <contact(a)mcclunetechnologies.net> 51 1 Gentoo <contact(a)gentoo.org> 52 1 Fermi National Accelerator Laboratory <fermilab(a)fnal.gov> 53 1 Eayun <contact(a)eayun.com> 54 1 Digital Pacific <contact(a)digitalpacific.com.au> 55 1 CloudFerro <contact(a)cloudferro.com> 56 1 Boston University <contact(a)bu.edu> Reviews, by authors (one review spans multiple commits) 1 276 Anthony D Atri <anthony.datri(a)gmail.com> 2 256 Venky Shankar <vshankar(a)redhat.com> 3 224 Samuel Just <sjust(a)redhat.com> 4 185 Adam King <adking(a)redhat.com> 5 183 Casey Bodley <cbodley(a)redhat.com> 6 158 Ernesto Puerta <epuertat(a)redhat.com> 7 147 Kefu Chai <kchai(a)redhat.com> 8 132 Ilya Dryomov <idryomov(a)redhat.com> 9 127 Nizamudeen A <nia(a)redhat.com> 10 123 Cole Mitchell <cole.mitchell.ceph(a)gmail.com> 11 93 Yingxin Cheng <yingxin.cheng(a)intel.com> 12 93 Neha Ojha <nojha(a)redhat.com> 13 91 Laura Flores <lflores(a)ibm.com> 14 88 Pere Diaz Bou <pdiazbou(a)redhat.com> 15 86 Radoslaw Zarzynski <rzarzynski(a)redhat.com> 16 79 Daniel Gryniewicz <dang(a)redhat.com> 17 77 Avan Thakkar <athakkar(a)redhat.com> 18 64 Redouane Kachach <rkachach(a)redhat.com> 19 62 Patrick Donnelly <pdonnell(a)redhat.com> 20 60 Ramana Raja <rraja(a)redhat.com> 21 60 Kotresh Hiremath Ravishankar <khiremat(a)redhat.com> 22 56 Aashish Sharma <aasharma(a)redhat.com> 23 54 Michael Fritch <mfritch(a)suse.com> 24 49 Josh Durgin <jdurgin(a)redhat.com> 25 43 John Mulligan <jmulligan(a)redhat.com> 26 40 Matt Benjamin <mbenjamin(a)redhat.com> 27 40 Adam C. Emerson <aemerson(a)redhat.com> 28 36 Mykola Golub <mykola.golub(a)clyso.com> 29 35 Rishabh Dave <ridave(a)redhat.com> 30 35 Dhairya Parmar <dparmar(a)redhat.com> 31 33 Milind Changire <mchangir(a)redhat.com> 32 33 Chunmei Liu <chunmei.liu(a)intel.com> 33 31 Xiubo Li <xiubli(a)redhat.com> 34 31 Ronen Friedman <rfriedma(a)redhat.com> 35 29 Matan Breizman <mbreizma(a)redhat.com> 36 29 Jos Collin <jcollin(a)redhat.com> 37 28 Pedro Gonzalez Gomez <pegonzal(a)redhat.com> 38 26 Zac Dover <zac.dover(a)proton.me> 39 26 Xuehan Xu <xuxuehan(a)qianxin.com> 40 26 Ali Maredia <amaredia(a)redhat.com> 41 26 Adam Kupczyk <akupczyk(a)ibm.com> 42 25 Yuval Lifshitz <ylifshit(a)redhat.com> 43 24 Deepika Upadhyay <dupadhya(a)redhat.com> 44 23 Sunil Angadi <Sunil.Angadi(a)ibm.com> 45 21 Neeraj Pratap Singh <Neeraj.Pratap.Singh1(a)ibm.com> 46 19 Nikhilkumar Shelke <nshelke(a)redhat.com> 47 19 Myoungwon Oh <myoungwon.oh(a)samsung.com> 48 19 Igor Fedotov <igor.fedotov(a)croit.io> 49 19 Greg Farnum <gfarnum(a)redhat.com> 50 18 Soumya Koduri <skoduri(a)redhat.com> 51 17 J. Eric Ivancich <ivancich(a)redhat.com> 52 17 Alfonso Martínez <almartin(a)redhat.com> 53 16 Shilpa Jagannath <smanjara(a)redhat.com> 54 13 Sarthak Gupta <sargupta(a)redhat.com> 55 13 Christopher Hoffman <choffman(a)redhat.com> 56 11 Arthur Outhenin-Chalandre <arthur.outhenin-chalandre(a)cern.ch> 57 10 Yuri Weinstein <yuriw(a)redhat.com> 58 10 Yaarit Hatuka <yaarit(a)redhat.com> 59 9 Volker Theile <vtheile(a)suse.com> 60 9 Tim Serong <tserong(a)suse.com> 61 9 Sebastian Wagner <swagner(a)redhat.com> 62 8 Lucian Petrut <lpetrut(a)cloudbasesolutions.com> 63 8 Ken Dreyer <kdreyer(a)redhat.com> 64 8 Guillaume Abrioux <gabrioux(a)ibm.com> 65 8 Aishwarya Mathuria <amathuri(a)redhat.com> 66 7 Juan Miguel Olmo Martínez <jolmomar(a)redhat.com> 67 7 David Galloway <dgallowa(a)redhat.com> 68 7 Brad Hubbard <bhubbard(a)redhat.com> 69 6 Zhang Song <zhangsong325(a)gmail.com> 70 6 Paul Cuzner <pcuzner(a)ibm.com> 71 6 Patrick Seidensal <pseidensal(a)suse.com> 72 6 Nitzan Mordechai <nmordech(a)redhat.com> 73 6 Mark Kogan <mkogan(a)redhat.com> 74 5 Vikhyat Umrao <vikhyat(a)redhat.com> 75 5 Sunny Kumar <sunkumar(a)redhat.com> 76 5 Mark Nelson <mark.nelson(a)clyso.com> 77 5 Kamoltat Sirivadhna <ksirivad(a)redhat.com> 78 5 Justin Caratzas <jcaratza(a)redhat.com> 79 5 Cory Snyder <csnyder(a)1111systems.com> 80 4 Yehuda Sadeh <ysadehwe(a)redhat.com> 81 4 Waad Alkhoury <walkhour(a)redhat.com> 82 4 Tatjana Dehler <tdehler(a)suse.com> 83 4 Sridhar Seshasayee <sseshasa(a)redhat.com> 84 4 Ngwa Sedrick Meh <nsedrick101(a)gmail.com> 85 4 Melissa Li <melissali(a)redhat.com> 86 3 Travis Nielsen <tnielsen(a)redhat.com> 87 3 Teoman Onay <tonay(a)redhat.com> 88 3 Pritha Srivastava <prsrivas(a)redhat.com> 89 3 Liu-Chunmei <chunmei.liu(a)intel.com> 90 3 Jeff Layton <jlayton(a)redhat.com> 91 3 Francesco Pantano <fpantano(a)redhat.com> 92 3 Dan van der Ster <daniel.vanderster(a)cern.ch> 93 2 Willem Jan Withagen <wjw(a)digiware.nl> 94 2 Sébastien Han <shan(a)redhat.com> 95 2 Sage Weil <sweil(a)redhat.com> 96 2 Rongqi Sun <sunrongqi(a)huawei.com> 97 2 Prashant D <pdhange(a)redhat.com> 98 2 Or Friedmann <ofriedma(a)redhat.com> 99 2 Nathan Cutler <ncutler(a)suse.com> 100 2 Luís Henriques <lhenriques(a)suse.com> 101 2 Gal Salomon <gsalomon(a)redhat.com> 102 2 Abhishek Lekshmanan <abhishek.lekshmanan(a)cern.ch> 103 1 Zack Cerza <zack(a)redhat.com> 104 1 Yixin Jin <yjin(a)akamai.com> 105 1 Yibo Cai <yibo.cai(a)arm.com> 106 1 Xie Xingguo <xie.xingguo(a)zte.com.cn> 107 1 Vallari Agrawal <val.agl002(a)gmail.com> 108 1 Umanga Chapagain <chapagainumanga(a)gmail.com> 109 1 Teoman Onay <tonay(a)ibm.com> 110 1 Sining Wu <sining.wu(a)seagate.com> 111 1 sherrif10 <NOT@FOUND> 112 1 Robin H. Johnson <rjohnson(a)digitalocean.com> 113 1 Omri Zeneva <ozeneva(a)redhat.com> 114 1 luo rixin <luorixin(a)huawei.com> 115 1 Krunal Chheda <kchheda3(a)bloomberg.net> 116 1 Kalpesh Pandya <kapandya(a)redhat.com> 117 1 Jenkins <jenkins(a)ceph.com> 118 1 Haomai Wang <haomai(a)xsky.com> 119 1 Han Fengzhe <hanfengzhe(a)hisilicon.com> 120 1 Gabriel BenHanokh <gbenhano(a)redhat.com> 121 1 Dan Mick <dmick(a)redhat.com> 122 1 Daniel Persson <mailto.woden(a)gmail.com> 123 1 Chunsong Feng <fengchunsong(a)huawei.com> 124 1 Bryan Montalvan <bmontalv(a)redhat.com> 125 1 Boris Ranto <branto(a)redhat.com> 126 1 Ankush Behl <cloudbehl(a)gmail.com> 127 1 Aaryan Porwal <aaryanporwal2233(a)gmail.com> Reviews, by organizations (one review spans multiple commits) 1 3069 Red Hat <contact(a)redhat.com> 2 415 Unaffiliated <no(a)organization.net> 3 137 SUSE <contact(a)suse.com> 4 129 Intel <contact(a)intel.com> 5 26 Qianxin <contact(a)qianxin.com> 6 26 Ceph Foundation <membership(a)linuxfoundation.org> 7 25 IBM <contact(a)IBM.com> 8 19 Samsung <contact(a)samsung.com> 9 15 CERN <contact(a)cern.ch> 10 8 Cloudbase Solutions <contact(a)cloudbasesolutions.com> 11 5 Croit <contact(a)croit.io> 12 5 11:11 Systems <contact(a)1111systems.com> 13 4 Huawei <contact(a)huawei.com> 14 2 Digiware <contact(a)digiware.nl> 15 1 ZTE <contact(a)zte.com.cn> 16 1 XSky <contact(a)xsky.com> 17 1 Seagate Technology <contact(a)seagate.com> 18 1 Inktank <contact(a)inktank.com> 19 1 HiSlicon <contact(a)hisilicon.com> 20 1 DreamHost <contact(a)dreamhost.com> 21 1 Bloomberg <opensource(a)bloomberg.net> 22 1 ARM <contact(a)arm.com> 23 1 Akamai Technologies <contact(a)akamai.com>

8 months, 3 weeks

1
0
0 0

Ceph Leadership Team Meeting: 2023-08-16 Minutes

by Casey Bodley

* following up on the recent issue of teuthology's /home directory filling up, Patrick is testing the use of home directories on cephfs. Laura, Yuri, and Venky volunteered their home directories for additional testing * more admin permissions were granted for core infrastructure to help resolve lab issues: see https://pad.ceph.com/p/ceph-infra-contact-sheet * backport testing for pacific 16.2.14 is nearly complete and qa validation may start next week

8 months, 3 weeks

1
0
0 0

Re: [ceph-users] Re: Can't join new mon - lossy channel, failing

by Josef Johansson

Hi, Let's do some serious necromancy here. I just had this exact problem. Turns out that after rebooting all nodes (one at the time of course), the monitor could join perfectly. Why? You tell me. We did not see any traces of the ip address in any dumps that we could get a hold of. I restarted all ceph-mgr beforehand as well. Med vänliga hälsningar Josef Johansson On 10/5/21 15:37, Konstantin Shalygin wrote: > As last resort we've change ipaddr of this host, and mon successfully joined to quorum. When revert ipaddr back - mon can't join, we think there something on switch side or on old mon's side. From old mon's I was checked new mon process connectivity via telnet - all works > It's good to make a some reproducer of this network problem to know what exactly message of ceph protocol is broken > > > > k > > _______________________________________________ > ceph-users mailing list -- ceph-users(a)ceph.io > To unsubscribe send an email to ceph-users-leave(a)ceph.io

8 months, 3 weeks

2
3
0 0

Reef regression: Unable to create per host RGW SSL certificates?

by j.r.roodhart＠uva.nl

On Quincy (17.2.6) we are able to use per host RGW SSL certificates using: ```shell echo "{{ host_ssl_crt }}" | ceph config-key set rgw/cert/{{ realmname }}/{{ zonename> }}{{ hostname }}.crt -i - echo "{{ host_ssl_key }}" | ceph config-key set rgw/cert/{{ realmname }}/{{ zonename> }}{{ hostname }}.key -i - ``` Logging on 17.2.6 shows: ``` Aug 14 14:41:01 ceph-dev-gw2 radosgw[1373]: framework conf key: ssl_certificate, val: config://rgw/cert/_ Realmname _/_ Zonename _/ceph-dev-gw2.crt Aug 14 14:41:01 ceph-dev-gw2 radosgw[1373]: framework conf key: ssl_private_key, val: config://rgw/cert/_ Realmname _/_ Zonename _/ceph-dev-gw2.key ``` On reef (18.2.0) this fails and the logging shows: ``` Aug 15 10:50:17 ceph-dev-gw2 radosgw[178335]: framework conf key: ssl_certificate, val: config://rgw/cert/$realm/$zone.crt Aug 15 10:50:17 ceph-dev-gw2 radosgw[178335]: framework conf key: ssl_private_key, val: config://rgw/cert/$realm/$zone.key ``` Is this a regression or should we configure this in another was? With kind regards, Jeroen

8 months, 3 weeks

1
0
0 0

ticket for cmake expert

by Patrick Donnelly

I'd appreciate if any cmake experts could look into this: https://tracker.ceph.com/issues/62428 -- Patrick Donnelly, Ph.D. He / Him / His Red Hat Partner Engineer IBM, Inc. GPG: 19F28A586F808C2402351B93C3301A3E258DD79D

8 months, 4 weeks

1
0
0 0

2024

2023

2022

2021

2020

2019

Dev August 2023