January 2020 - ceph-users

by Florian Pritz

Hi, When we tried putting some load on our test cephfs setup by restoring a backup in artifactory, we eventually ran out of space (around 95% used in `df` = 3.5TB) which caused artifactory to abort the restore and clean up. However, while a simple `find` no longer shows the files, `df` still claims that we have around 2.1TB of data on the cephfs. `df -i` also shows 2.4M used inodes. When using `du -sh` on a top-level mountpoint, I get 31G used, which is data that is still really here and which is expected to be here. Consequently, we also get the following warning: > MANY_OBJECTS_PER_PG 1 pools have many more objects per pg than average > pool cephfs_data objects per pg (38711) is more than 231.802 times cluster average (167) We are running ceph 14.2.5. We have snapshots enabled on cephfs, but there are currently no active snapshots listed by `ceph daemon mds.$hostname dump snaps --server` (see below). I can't say for sure if we created snapshots during the backup restore. > { > "last_snap": 39, > "last_created": 38, > "last_destroyed": 39, > "pending_noop": [], > "snaps": [], > "need_to_purge": {}, > "pending_update": [], > "pending_destroy": [] > } We only have a single CephFS. We use the pool_namespace xattr for our various directory trees on the cephfs. `ceph df` shows: > POOL ID STORED OBJECTS USED %USED MAX AVAIL > cephfs_data 6 2.1 TiB 2.48M 2.1 TiB 24.97 3.1 TiB `ceph daemon mds.$hostname perf dump | grep stray` shows: > "num_strays": 0, > "num_strays_delayed": 0, > "num_strays_enqueuing": 0, > "strays_created": 5097138, > "strays_enqueued": 5097138, > "strays_reintegrated": 0, > "strays_migrated": 0, `rados -p cephfs_data df` shows: > POOL_NAME USED OBJECTS CLONES COPIES MISSING_ON_PRIMARY UNFOUND DEGRADED RD_OPS RD WR_OPS WR USED COMPR UNDER COMPR > cephfs_data 2.1 TiB 2477540 0 4955080 0 0 0 10699626 6.9 TiB 86911076 35 TiB 0 B 0 B > > total_objects 29718 > total_used 329 GiB > total_avail 7.5 TiB > total_space 7.8 TiB When I combine the usage and the free space shown by `df` we would exceed our cluster size. Our test cluster currently has 7.8TB total space with a replication size of 2 for all pools. With 2.1TB "used" on the cephfs according to `df` + 3.1TB being shows as "free" I get 5.2TB total size. This would mean >10TB of data when accounted for replication. Clearly this can't fit on a cluster with only 7.8TB of capacity. Do you have any ideas why we see so many objects and so much reported usage? Is there any way to fix this without recreating the cephfs? Florian -- Florian Pritz Research Industrial Systems Engineering (RISE) Forschungs-, Entwicklungs- und Großprojektberatung GmbH Concorde Business Park F 2320 Schwechat Austria E-Mail: florian.pritz(a)rise-world.com Web: www.rise-world.com Firmenbuch: FN 280353i Landesgericht Korneuburg UID: ATU62886416

4 years, 3 months

3
15
0 0

Re: CephFS with cache-tier kernel-mount client unable to write (Nautilus)

by Ilya Dryomov

On Thu, Jan 23, 2020 at 2:36 PM Ilya Dryomov <idryomov(a)gmail.com> wrote: > > On Wed, Jan 22, 2020 at 6:18 PM Hayashida, Mami <mami.hayashida(a)uky.edu> wrote: > > > > Thanks, Ilya. > > > > I just tried modifying the osd cap for client.testuser by getting rid of "tag cephfs data=cephfs_test" part and confirmed this key does work (i.e. lets the CephFS client read/write). It now reads: > > > > [client.testuser] > > key = XXXYYYYZZZ > > caps mds = "allow rw" > > caps mon = "allow r" > > caps osd = "allow rw" // previously "allow rw tag cephfs data=cephfs_test" > > > > I tried removing either "tag cephfs" or "data=cephfs_test" (and leaving the other), but neither worked. > > > > Now, here is my question: will not having the "allow rw tag cephfs data=<file system name>" (under osd caps) result in a security/privacy loophole in a production cluster? (I am still trying to assess whether having a Cache Tier behind CephFS is worth all the headaches...) > > It's probably not worth it. Unless you have a specific tiered > workload in mind and your cache pool is large enough for it, I'd > recommend staying away from cache tiering. > > "allow rw" for osd is only marginally more restrictive than > client.admin's "allow *", allowing the user to read/write every object > in the cluster. Scratch my reply about doing it by hand -- try the > following: > > $ ceph osd pool application enable cephfs-data-cache cephfs > $ ceph osd pool application set cephfs-data-cache cephfs data cephfs_test > $ ceph fs authorize cephfs_test ... (as before) > > You will see the same "allow rw tag cephfs data=cephfs_test" cap in > "ceph auth list" output, but it should allow accessing cephfs-data-cache. Dropping ceph-users(a)lists.ceph.com and resending to ceph-users(a)ceph.io. Thanks, Ilya

4 years, 3 months

2
2
0 0

Google Summer of Code 2020

by Alastair Dewhurst - UKRI STFC

Hello I apologies if I have missed an announcement, but I can’t find anything regarding if Ceph will participate in the GSoC this year? The only thing I could find was last years announcement (see below) and webpage. My organisation has some ideas for Ceph projects, however we could submit them under a different banner organisation if necessary. Thanks Alastair On 17 Jan 2019, at 08:12, Mike Perez <miperez(a)redhat.com<mailto:miperez@redhat.com>> wrote: Hello everyone, We're getting ready for the next round of Google Summer of Code and Outreachy. Ali Maredia and I will help organize the Ceph project for each program. We are looking to have project ideas for Google Summer of Code by February 4th as our project application deadline is due by February 6th. https://ceph.com/contribute/gsoc2019/ https://summerofcode.withgoogle.com/how-it-works/ Outreachy applicants in mid-February through the end of March will begin selecting open source projects to work on and make small contributions. On April 12th we hope to have some projects set for Outreachy so we can start selecting applicants. End of May will begin the internships. https://www.outreachy.org/mentor/ You can submit project ideas for both programs on this etherpad. https://pad.ceph.com/p/project-ideas Stay tuned for more updates. -- Mike Perez (thingee) _______________________________________________ ceph-users mailing list ceph-users(a)lists.ceph.com<mailto:ceph-users@lists.ceph.com> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

4 years, 3 months

1
0
0 0

cephfs kernel mount option uid?

by Marc Roos

Is it possible to mount a cephfs with a specific uid or gid? To make it available to a 'non-root' user?

4 years, 3 months

2
1
0 0

Problem : "1 pools have many more objects per pg than average"

by St-Germain, Sylvain (SSC/SPC)

///////////////////////// Problem /////////////////////////// I've got a Warning on my cluster that I cannot remove : "1 pools have many more objects per pg than average" Does somebody has some insight ? I think it's normal to have this warning because I have just one pool in use, but how can I remove this warning ? Thx ! ///////////////////////// INFORMATION /////////////////////////// *** Here's some information about the cluster # ceph health detail HEALTH_WARN 1 pools have many more objects per pg than average MANY_OBJECTS_PER_PG 1 pools have many more objects per pg than average pool default.rgw.buckets.data objects per pg (50567) is more than 14.1249 times cluster average (3580) # sudo ceph-conf -D | grep mon_pg_warn_max_object_skew mon_pg_warn_max_object_skew = 10.000000 # ceph daemon mon.dao-wkr-04 config show | grep mon_pg_warn_max_object_skew "mon_pg_warn_max_object_skew": "10.000000" # ceph -v ceph version 14.2.4 (75f4de193b3ea58512f204623e6c5a16e6c1e1ba) nautilus (stable) # ceph df RAW STORAGE: CLASS SIZE AVAIL USED RAW USED %RAW USED hdd 873 TiB 823 TiB 50 TiB 51 TiB 5.80 TOTAL 873 TiB 823 TiB 50 TiB 51 TiB 5.80 POOLS: POOL ID STORED OBJECTS USED %USED MAX AVAIL .rgw.root 11 3.5 KiB 8 1.5 MiB 0 249 TiB default.rgw.control 12 0 B 8 0 B 0 249 TiB default.rgw.meta 13 52 KiB 186 34 MiB 0 249 TiB default.rgw.log 14 0 B 207 0 B 0 249 TiB default.rgw.buckets.index 15 1.2 GiB 131 1.2 GiB 0 249 TiB cephfs_data 29 915 MiB 202 1.5 GiB 0 467 TiB cephfs_metadata 30 145 KiB 23 2.1 MiB 0 249 TiB default.rgw.buckets.data 31 30 TiB 12.95M 50 TiB 6.32 467 TiB # ceph osd dump | grep default.rgw.buckets.data pool 31 'default.rgw.buckets.data' erasure size 8 min_size 6 crush_rule 2 object_hash rjenkins pg_num 256 pgp_num 256 autoscale_mode on last_change 9502 lfor 0/2191/7577 flags hashpspool stripe_width 20480 target_size_ratio 0.4 application rgw /////////////////////////// SOLUTION TRIED /////////////////////////// 1- I try to increase the value of mon_pg_warn_max_object_skew parameter #sudo ceph tell mon.* injectargs '--mon_pg_warn_max_object_skew 20' #sudo ceph tell osd.* injectargs '--mon_pg_warn_max_object_skew 20' + And reboot the monitor The parameter didn't change.

4 years, 3 months

1
0
0 0

Fwd: OSD crash after change of osd_memory_target

by Martin Mlynář

Hi Igor, unfortunately same result: # ceph config dump WHO MASK LEVEL OPTION VALUE RO osd basic osd_memory_target 2147483648 # /usr/bin/ceph-osd -d --cluster ceph --id 0 --setuser ceph --setgroup ceph .... 0> 2020-01-23 10:48:04.436 7fc61b5b5c80 -1 *** Caught signal (Aborted) ** in thread 7fc61b5b5c80 thread_name:ceph-osd ceph version 14.2.6 (f0aa067ac7a02ee46ea48aa26c6e298b5ea272e9) nautilus (stable) 1: (()+0x12730) [0x7fc61c05d730] 2: (gsignal()+0x10b) [0x7fc61bb417bb] 3: (abort()+0x121) [0x7fc61bb2c535] 4: (()+0x8c983) [0x7fc61bef4983] 5: (()+0x928c6) [0x7fc61befa8c6] 6: (()+0x92901) [0x7fc61befa901] 7: (()+0x92b34) [0x7fc61befab34] 8: (()+0x5a3f53) [0x55ecdabb2f53] 9: (Option::size_t const md_config_t::get_val<Option::size_t>(ConfigValues const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) const+0x81) [0x55ecdabb8c91] 10: (BlueStore::_set_cache_sizes()+0x15a) [0x55ecdb033d8a] 11: (BlueStore::_open_bdev(bool)+0x173) [0x55ecdb036b23] 12: (BlueStore::get_devices(std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)+0xef) [0x55ecdb09d7ef] 13: (BlueStore::get_numa_node(int*, std::set<int, std::less<int>, std::allocator<int> >*, std::set<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >*)+0x7b) [0x55ecdb04571b] 14: (main()+0x2870) [0x55ecdab80440] 15: (__libc_start_main()+0xeb) [0x7fc61bb2e09b] 16: (_start()+0x2a) [0x55ecdabb2c6a] NOTE: a copy of the executable, or `objdump -rdS <executable>` is needed to interpret this. .... Best Regards, Martin Dne 22. 01. 20 v 16:33 Igor Fedotov napsal(a): > > Hi Martin, > > looks like a bug to me. > > You might want to remove all custom settings from config database and > try to set osd-memory-target only. > > Would it help? > > > Thanks, > > Igor > > On 1/22/2020 3:43 PM, Martin Mlynář wrote: >> >> >> Dne 21. 01. 20 v 21:12 Stefan Kooman napsal(a): >>> Quoting Martin Mlynář (nexus+ceph(a)smoula.net): >>> >>>> Do you think this could help? OSD does not even start, I'm getting a little >>>> lost how flushing caches could help. >>> I might have mis-understood. I though the OSDs crashed when you set the >>> config setting. >>> >>>> According to trace I suspect something around processing config values. >>> I've just set the same config setting on a test cluster and restarted an >>> OSD without problem. So, not sure what is going on there. >>> >>> Gr. Stefan >> >> I've compiled ceph-osd with debug symbols and got better backtrace: >> >> -24> 2020-01-22 13:12:53.614 7f83ed064700 4 set_mon_vals no >> callback set >> -23> 2020-01-22 13:12:53.614 7f83ee867700 10 monclient: discarding >> stray monitor message auth_reply(proto 2 0 (0) Success) v1 >> -22> 2020-01-22 13:12:53.614 7f83ed064700 10 set_mon_vals >> osd_crush_update_on_start = true >> -21> 2020-01-22 13:12:53.614 7f83ed064700 10 set_mon_vals >> osd_max_backfills = 64 >> -20> 2020-01-22 13:12:53.614 7f83ed064700 10 set_mon_vals >> osd_memory_target = 2147483648 >> -19> 2020-01-22 13:12:53.614 7f83ed064700 10 set_mon_vals >> osd_recovery_max_active = 40 >> -18> 2020-01-22 13:12:53.614 7f83ed064700 10 set_mon_vals >> osd_recovery_max_single_start = 1000 >> -17> 2020-01-22 13:12:53.614 7f83ed064700 10 set_mon_vals >> osd_recovery_sleep_hdd = 0.000000 >> -16> 2020-01-22 13:12:53.614 7f83ed064700 10 set_mon_vals >> osd_recovery_sleep_hybrid = 0.000000 >> -15> 2020-01-22 13:12:53.627 7f83f0276c40 0 set uid:gid to >> 64045:64045 (ceph:ceph) >> -14> 2020-01-22 13:12:53.627 7f83f0276c40 0 ceph version 14.2.6 >> (f0aa067ac7a02ee46ea48aa26c6e298b5ea272e9) nautilus (stable), process >> ceph-osd, pid 1111622 >> -13> 2020-01-22 13:12:53.649 7f83f0276c40 0 pidfile_write: ignore >> empty --pid-file >> -12> 2020-01-22 13:12:53.657 7f83f0276c40 5 asok(0x5580518fa000) >> init /var/run/ceph/ceph-osd.6.asok >> -11> 2020-01-22 13:12:53.657 7f83f0276c40 5 asok(0x5580518fa000) >> bind_and_listen /var/run/ceph/ceph-osd.6.asok >> -10> 2020-01-22 13:12:53.657 7f83f0276c40 5 asok(0x5580518fa000) >> register_command 0 hook 0x558051872fc0 >> -9> 2020-01-22 13:12:53.657 7f83f0276c40 5 asok(0x5580518fa000) >> register_command version hook 0x558051872fc0 >> -8> 2020-01-22 13:12:53.657 7f83f0276c40 5 asok(0x5580518fa000) >> register_command git_version hook 0x558051872fc0 >> -7> 2020-01-22 13:12:53.657 7f83f0276c40 5 asok(0x5580518fa000) >> register_command help hook 0x558051874220 >> -6> 2020-01-22 13:12:53.657 7f83f0276c40 5 asok(0x5580518fa000) >> register_command get_command_descriptions hook 0x558051874260 >> -5> 2020-01-22 13:12:53.657 7f83ed865700 5 asok(0x5580518fa000) >> entry start >> -4> 2020-01-22 13:12:53.670 7f83f0276c40 5 object store type is >> bluestore >> -3> 2020-01-22 13:12:53.675 7f83f0276c40 1 bdev create path >> /var/lib/ceph/osd/ceph-6/block type kernel >> -2> 2020-01-22 13:12:53.675 7f83f0276c40 1 bdev(0x5580518f3f80 >> /var/lib/ceph/osd/ceph-6/block) open path /var/lib/ceph/osd/ceph-6/block >> -1> 2020-01-22 13:12:53.675 7f83f0276c40 1 bdev(0x5580518f3f80 >> /var/lib/ceph/osd/ceph-6/block) open size 3000588304384 >> (0x2baa1000000, 2.7 TiB) block_size 4096 (4 KiB) rotational discard >> not supported >> 0> 2020-01-22 13:12:53.714 7f83f0276c40 -1 *** Caught signal >> (Aborted) ** >> in thread 7f83f0276c40 thread_name:ceph-osd >> >> ceph version 14.2.6 (f0aa067ac7a02ee46ea48aa26c6e298b5ea272e9) >> nautilus (stable) >> 1: (()+0x2c19654) [0x558045ec6654] >> 2: (()+0x12730) [0x7f83f0d1f730] >> 3: (gsignal()+0x10b) [0x7f83f08027bb] >> 4: (abort()+0x121) [0x7f83f07ed535] >> 5: (()+0x8c983) [0x7f83f0bb5983] >> 6: (()+0x928c6) [0x7f83f0bbb8c6] >> 7: (()+0x92901) [0x7f83f0bbb901] >> 8: (()+0x92b34) [0x7f83f0bbbb34] >> * 9: (void boost::throw_exception<boost::bad_get>(boost::bad_get >> const&)+0x7b) [0x5580454d5430]* >> * 10: (Option::size_t&& boost::relaxed_get<Option::size_t, >> boost::blank, std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> >, unsigned long, long, >> double, bool, entity_addr_t, entity_addrvec_t, >> std::chrono::duration<long, std::ratio<1l, 1l> >, Option::size_t, >> uuid_d>(boost::variant<boost::blank, std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> >, unsigned long, long, >> double, bool, entity_addr_t, entity_addrvec_t, >> std::chrono::duration<long, std::ratio<1l, 1l> >, Option::size_t, >> uuid_d>&&)+0x5b) [0x5580454d6223]* >> 11: (Option::size_t&& boost::strict_get<Option::size_t, >> boost::blank, std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> >, unsigned long, long, >> double, bool, entity_addr_t, entity_addrvec_t, >> std::chrono::duration<long, std::ratio<1l, 1l> >, Option::size_t, >> uuid_d>(boost::variant<boost::blank, std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> >, unsigned long, long, >> double, bool, entity_addr_t, entity_addrvec_t, >> std::chrono::duration<long, std::ratio<1l, 1l> >, Option::size_t, >> uuid_d>&&)+0x20) [0x5580454d4a39] >> 12: (Option::size_t&& boost::get<Option::size_t, boost::blank, >> std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> >, unsigned long, long, double, bool, >> entity_addr_t, entity_addrvec_t, std::chrono::duration<long, >> std::ratio<1l, 1l> >, Option::size_t, >> uuid_d>(boost::variant<boost::blank, std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> >, unsigned long, long, >> double, bool, entity_addr_t, entity_addrvec_t, >> std::chrono::duration<long, std::ratio<1l, 1l> >, Option::size_t, >> uuid_d>&&)+0x20) [0x5580454d1ed7] >> 13: (Option::size_t const >> md_config_t::get_val<Option::size_t>(ConfigValues const&, >> std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> > const&) const+0x48) [0x5580454ce882] >> 14: (Option::size_t const >> ConfigProxy::get_val<Option::size_t>(std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> > const&) const+0x58) >> [0x5580454cb9b8] >> 15: (BlueStore::_set_cache_sizes()+0x159) [0x558045ce2213] >> 16: (BlueStore::_open_bdev(bool)+0x301) [0x558045ce6be3] >> 17: >> (BlueStore::get_devices(std::set<std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> >, >> std::less<std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> > >, >> std::allocator<std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> > > >*)+0xf9) >> [0x558045d0f16d] >> 18: (BlueStore::get_numa_node(int*, std::set<int, std::less<int>, >> std::allocator<int> >*, std::set<std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> >, >> std::less<std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> > >, >> std::allocator<std::__cxx11::basic_string<char, >> std::char_traits<char>, std::allocator<char> > > >*)+0x79) >> [0x558045d0eb55] >> 19: (main()+0x3aae) [0x5580454c2460] >> 20: (__libc_start_main()+0xeb) [0x7f83f07ef09b] >> 21: (_start()+0x2a) [0x5580454bda2a] >> NOTE: a copy of the executable, or `objdump -rdS <executable>` is >> needed to interpret this. >> >> And managed some gdb debugging (int BlueStore::_set_cache_sizes()): >> >> (gdb) n >> 4116 cache_autotune_interval = >> (gdb) n >> 4117 >> cct->_conf.get_val<double>("bluestore_cache_autotune_interval"); >> (gdb) p cache_autotune_interval >> $3 = 5 >> (gdb) n >> 4118 osd_memory_target = >> cct->_conf.get_val<Option::size_t>("osd_memory_target"); >> (gdb) s >> std::__cxx11::basic_string<char, std::char_traits<char>, >> std::allocator<char> >::basic_string<std::allocator<char> > >> (this=0x7fffffffc140, __s=0x555558d26c2f "osd_memory_target", __a=...) >> at /usr/include/c++/8/bits/basic_string.h:515 >> 515 : _M_dataplus(_M_local_data(), __a) >> (gdb) n >> 516 { _M_construct(__s, __s ? __s + traits_type::length(__s) >> : __s+npos); } >> (gdb) >> terminate called after throwing an instance of >> 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_get> >> >' >> what(): boost::bad_get: failed value get using boost::get >> >> But there I'm stuck. GDBing c++ code is a really dark sorcery for me. >> >> Other get_vals look fine, maybe get_val<*Option::size_t*> is the >> problem? It looks like trouble outside of ceph - what system are you >> testing on? This is debian with official debian build from >> buster-backports. Maybe some of debian's patches? >> >> -- >> Martin Mlynář >> >> _______________________________________________ >> ceph-users mailing list >> ceph-users(a)lists.ceph.com >> http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

4 years, 3 months

1
0
0 0

Ceph at DevConf and FOSDEM

by Mike Perez

Hi Cephers, We will have a booth at DevConf this year! https://www.devconf.info/cz/ If you're interested in helping at the booth at DevConf, please reply to me directly, and I can provide more details. I'm still working on getting a shared booth for FOSDEM with the CentOS table. Also, I will try to get us signed with a BoF session. If you're interested, please also let me know directly. Thanks! https://fosdem.org/2020/ -- Mike Perez he/him Ceph Community Manager M: +1-951-572-2633 494C 5D25 2968 D361 65FB 3829 94BC D781 ADA8 8AEA @Thingee <https://twitter.com/thingee> Thingee <https://www.linkedin.com/thingee> <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

4 years, 3 months

1
1
0 0

Upcoming Ceph Days for 2020

by Mike Perez

Hi Cephers, We have just posted some upcoming Ceph Days. We are looking for sponsors and content: * Ceph Day Istanbul: March 17 * Ceph Day Oslo: May 13 * Ceph Day Vancouver: May 13 https://ceph.com/cephdays/ Also don't forget about our big event Cephalocon Seoul March 3-5. Registration, schedule. sponsorship and hotel information is available: https://ceph.io/cephalocon/seoul-2020/ If you have any questions about these events, please contact us at events(a)ceph.io. Any help with promoting these events is greatly appreciated. Thanks! -- Mike Perez he/him Ceph Community Manager M: +1-951-572-2633 494C 5D25 2968 D361 65FB 3829 94BC D781 ADA8 8AEA @Thingee <https://twitter.com/thingee> Thingee <https://www.linkedin.com/thingee> <https://www.facebook.com/RedHatInc> <https://www.redhat.com>

4 years, 3 months

1
0
0 0

Migrate Jewel from leveldb to rocksdb

by Robert LeBlanc

In the last release of Jewel [0] it mentions that omap data can be stored in rocksdb instead of leveldb. We are seeing high latencies from compaction of leveldb on our Jewel cluster (can't upgrade at this time). I installed the latest version, but apparently that is not enough to do the conversion. Is there a way to move OSDs from leveldb to rocksdb without trashing and rebuilding all the osds? [0] https://docs.ceph.com/docs/master/releases/jewel/ Thanks, Robert LeBlanc ---------------- Robert LeBlanc PGP Fingerprint 79A2 9CA4 6CC4 45DD A904 C70E E654 3BB2 FA62 B9F1

4 years, 3 months

3
3
0 0

Auto create rbd snapshots

by Marc Roos

Is it possible to schedule the creation of snapshots on specific rbd images within ceph?

4 years, 3 months

1
0
0 0

2024

2023

2022

2021

2020

2019

ceph-users January 2020