August 2020 - ceph-users

by hirkumispe＠enayu.com

Are you looking for Geek Squad Tech Support, Visit Geek Tech Support now, to compare the offers for Geek Squad Tech Support. All channel support plans. https://thegethelp.com/geek-squad-tech-support/ Get your devices protected under our geek protection plan. Check out our detailed guide on how egeek protection plan is better than the geek squad protection plan https://egeekonline.com/protection-plan/

3 years, 9 months

1
0
0 0

Get World-Class Programming Assignment Help at a Reasonable budget.

by keithmorris081＠gmail.com

Get it completed from the Top notch Assignment Writers for the Students across Universities across various countries. With the best in class turnaround time and also avail amazing value-added service, And Get in touch with the Best Programming Assignment Help who are very talented in providing solutions on various topics on subjects. You Read it Right! We are here to help you with your queries on your assignments. We are providing you with a world-class and Highly Talented Assignment expert. These Assignment Writers who are capable of doing any writing services, and many other writing services such as Assignment Writing Services, Assignment Help for various subjects such as Engineering Assignment, Statistics for the students across Australia, and also for students across UK, USA, Malaysia and various other countries. https://www.myassignmentservices.com/programming-assignment-help.html

3 years, 9 months

2
1
1 0

professional essay writing help

by keiratayor＠gmail.com

This professional help with writing essays for college not only provides flawless essays to the students but it also takes several initiatives to make the service comprehensive and inclusive for the students. Accordingly, the expert essay writer has published numerous history essay samples on the website. https://essayassignmenthelp.com.au/essay-writing-help.html

3 years, 9 months

1
0
0 0

Speeding up reconnection

by William Edwards

Hello, When connection is lost between kernel client, a few things happen: 1. Caps become stale: Aug 11 11:08:14 admin-cap kernel: [308405.227718] ceph: mds0 caps stale 2. MDS evicts client for being unresponsive: MDS log: 2020-08-11 11:12:08.923 7fd1f45ae700 0 log_channel(cluster) log [WRN] : evicting unresponsive client admin-cap.cf.ha.cyberfusion.cloud:DB0001-cap (144786749), after 300.978 seconds Client log: Aug 11 11:12:11 admin-cap kernel: [308643.051006] ceph: mds0 hung 3. Socket is closed: Aug 11 11:22:57 admin-cap kernel: [309289.192705] libceph: mds0 [fdb7:b01e:7b8e:0:10:10:10:1]:6849 socket closed (con state OPEN) I am not sure whether the kernel client or MDS closes the connection. I think the kernel client does so, because nothing is logged at the MDS side at 11:22:57 4. Connection is reset by MDS: MDS log: 2020-08-11 11:22:58.831 7fd1f9e49700 0 --1- [v2:[fdb7:b01e:7b8e:0:10:10:10:1]:6800/3619156441,v1:[fdb7:b01e:7b8e:0:10:10:10:1]:6849/3619156441] >> v1:[fc00:b6d:cfc:951::7]:0/133007863 conn(0x55bfaf1c2880 0x55c16cb47000 :6849 s=ACCEPTING_WAIT_CONNECT_MSG_AUTH pgs=0 cs=0 l=0).handle_connect_message_2 accept we reset (peer sent cseq 1), sending RESETSESSION Client log: Aug 11 11:22:58 admin-cap kernel: [309290.058222] libceph: mds0 [fdb7:b01e:7b8e:0:10:10:10:1]:6849 connection reset 5. Kernel client reconnects: Aug 11 11:22:58 admin-cap kernel: [309290.058972] ceph: mds0 closed our session Aug 11 11:22:58 admin-cap kernel: [309290.058973] ceph: mds0 reconnect start Aug 11 11:22:58 admin-cap kernel: [309290.069979] ceph: mds0 reconnect denied Aug 11 11:22:58 admin-cap kernel: [309290.069996] ceph: dropping file locks for 000000006a23d9dd 1099625041446 Aug 11 11:22:58 admin-cap kernel: [309290.071135] libceph: mds0 [fdb7:b01e:7b8e:0:10:10:10:1]:6849 socket closed (con state NEGOTIATING) Question: As you can see, there's 10 minutes between losing the connection and the reconnection attempt (11:12:08 - 11:22:58). I could not find any settings related to the period after which reconnection is attempted. I would like to change this value from 10 minutes to something like 1 minute. I also tried searching the Ceph docs for the string '600' (10 minutes), but did not find anything useful. Hope someone can help. Environment details: Client kernel: 4.19.0-10-amd64 Ceph version: ceph version 14.2.9 (bed944f8c45b9c98485e99b70e11bbcec6f6659a) nautilus (stable) Met vriendelijke groeten, William Edwards

3 years, 9 months

3
3
0 0

What The Benefit Of Choosing Epson Customer Service?

by mary smith

All together get profited by picking the right and trustworthy Epson Customer Service specialist co-ops, it is firmly prescribed to have a solid examination before engaging with any of such specialist organizations as there are a few phony organizations are likewise there professing to be the best yet really not. https://www.epsonprintersupportpro.net/

3 years, 9 months

1
0
0 0

Get the opportunity To Be Acquainted With HP Support Assistant In A Proper Manner.

by mary smith

So as to be familiar with the HP Support Assistant in an appropriate way, you ought not leave any stone unturned in moving toward the guaranteed printer specialists who will expertly help you the specific investigating answer for your issues in a powerful way. You can move toward them by simply utilizing distinctive advantageous methods at whenever. https://www.amiytech.com/hp-support-assistant/

3 years, 9 months

1
0
0 0

It takes long time for a newly added osd booting to up state due to heavy rocksdb activity

by Jerry Pu

Hi All We had a cluster (v13.2.4) with 32 osds in total. At first, an osd (osd.18) in cluster was down. So, we tried to remove the osd and added a new one (osd.32) with new ID. We unplugged the disk (osd.18) and plugged in a new disk in the same slot and add osd.32 into cluster. Then, osd.32 was booting, but, we found it takes much time (around 18 mins) for the osd to change to up state. Diving into osd.32 logs, we see that there is much rocksdb activity before osd.32 change to up state. Can anyone explain why this happened or give me any advice about how to prevent from this. Thanks. [osd.32 log] 2020-08-03 15:36:58.852 7f88021fa1c0 0 osd.32 0 done with init, starting boot process 2020-08-03 15:36:58.852 7f88021fa1c0 1 osd.32 0 start_boot 2020-08-03 15:36:58.854 7f87db02b700 -1 osd.32 0 waiting for initial osdmap 2020-08-03 15:36:58.855 7f87e4ba0700 -1 osd.32 0 failed to load OSD map for epoch 22010, got 0 bytes 2020-08-03 15:36:58.955 7f87e0836700 0 osd.32 22011 crush map has features 283675107524608, adjusting msgr requires for clients 2020-08-03 15:36:58.955 7f87e0836700 0 osd.32 22011 crush map has features 283675107524608 was 288232575208792577, adjusting msgr requires for mons *2020-08-03 15:36:58.955* 7f87e0836700 0 osd.32 22011 crush map has features 720859615486820352, adjusting msgr requires for osds 2020-08-03 15:37:31.182 7f87e1037700 4 rocksdb: [/home/gitlab/rpmbuild/BUILD/ceph-13.2.4/src/rocksdb/db/db_impl_write.cc:1346] [default] New memtable created with log file: #16. Immutable memtables: 0. 2020-08-03 15:37:31.285 7f87e8045700 4 rocksdb: (Original Log Time 2020/08/03-15:37:31.183995) [/home/gitlab/rpmbuild/BUILD/ceph-13.2.4/src/rocksdb/db/db_impl_compaction_flush.cc:1396] Calling FlushMemTableToOutputFile with column family [default], flush slots available 1, compaction slots available 1, flush slots scheduled 1, compaction slots scheduled 0 2020-08-03 15:37:31.285 7f87e8045700 4 rocksdb: [/home/gitlab/rpmbuild/BUILD/ceph-13.2.4/src/rocksdb/db/flush_job.cc:300] [default] [JOB 3] Flushing memtable with next log file: 16 -------- lots of rocksdb activity--------- 2020-08-03 15:54:21.704 7f87e8045700 4 rocksdb: (Original Log Time 2020/08/03-15:54:21.705680) [/home/gitlab/rpmbuild/BUILD/ceph-13.2.4/src/rocksdb/db/memtable_list.cc:397] [default] Level-0 commit table #112: memtable #1 done 2020-08-03 15:54:21.704 7f87e8045700 4 rocksdb: (Original Log Time 2020/08/03-15:54:21.705704) EVENT_LOG_v1 {"time_micros": 1596441261705697, "job": 51, "event": "flush_finished", "output_compression": "NoCompression", "lsm_state": [1, 3, 0, 0, 0, 0, 0], "immutable_memtables": 0} 2020-08-03 15:54:21.704 7f87e8045700 4 rocksdb: (Original Log Time 2020/08/03-15:54:21.705721) [/home/gitlab/rpmbuild/BUILD/ceph-13.2.4/src/rocksdb/db/db_impl_compaction_flush.cc:172] [default] Level summary: base level 1 max bytes base 268435456 files[1 3 0 0 0 0 0] max score 0.75 *2020-08-03 15:54:38.567* 7f87e0836700 1 osd.32 502096 state: booting -> active 2020-08-03 15:54:38.567 7f87d5820700 1 osd.32 pg_epoch: 502096 pg[1.17e( empty local-lis/les=0/0 n=0 ec=11627/16 lis/c 501703/501703 les/c/f 501704/501704/0 502096/502096/502096) [32,26,28] r=0 lpr=502096 pi=[501703,502096)/1 crt=0'0 mlcod 0'0 unknown mbc={}] state<Start>: transitioning to Primary Best Jerry

3 years, 9 months

1
0
0 0

v14.2.11 Nautilus released

by Abhishek Lekshmanan

We're happy to announce the availability of the eleventh release in the Nautilus series. This release brings a number of bugfixes across all major components of Ceph. We recommend that all Nautilus users upgrade to this release. Notable Changes --------------- * RGW: The `radosgw-admin` sub-commands dealing with orphans -- `radosgw-admin orphans find`, `radosgw-admin orphans finish`, `radosgw-admin orphans list-jobs` -- have been deprecated. They have not been actively maintained and they store intermediate results on the cluster, which could fill a nearly-full cluster. They have been replaced by a tool, currently considered experimental, `rgw-orphan-list`. * Now when noscrub and/or nodeep-scrub flags are set globally or per pool, scheduled scrubs of the type disabled will be aborted. All user initiated scrubs are NOT interrupted. * Fixed a ceph-osd crash in _committed_osd_maps when there is a failure to encode the first incremental map. issue#46443: https://github.com/ceph/ceph/pull/46443 For the detailed changelog please refer to the blog entry at https://ceph.io/releases/v14-2-11-nautilus-released/ Getting Ceph ------------ * Git at git://github.com/ceph/ceph.git * Tarball at http://download.ceph.com/tarballs/ceph-14.2.11.tar.gz * For packages, see http://docs.ceph.com/docs/master/install/get-packages/ * Release git sha1: f7fdb2f52131f54b891a2ec99d8205561242cdaf -- Abhishek Lekshmanan SUSE Software Solutions Germany GmbH GF: Felix Imendörffer, HRB 36809 (AG Nürnberg)

3 years, 9 months

1
0
0 0

ceph orch host rm seems to just move daemons out of cephadm, not remove them

by pixel fairy

made a cluster of 2 osd hosts, and one temp monitor. then added another osd host and did a "ceph orch host rm tempmon". this all in vagrant (libvirt), with the generic/ubuntu2004 box. INFO:cephadm:Inferring fsid 5426a59e-db33-11ea-8441-b913b695959d INFO:cephadm:Using recent ceph image ceph/ceph:v15 cluster: id: 5426a59e-db33-11ea-8441-b913b695959d health: HEALTH_WARN 2 stray daemons(s) not managed by cephadm 1 stray host(s) with 2 daemon(s) not managed by cephadm added 2 more osd hosts, and ceph -s gave me this, services: mon: 6 daemons, quorum ceph5,ceph4,tempmon,ceph3,ceph2,ceph1 (age 33m) mgr: ceph5.erdofb(active, since 82m), standbys: tempmon.xkrlmm, ceph3.xjuecs osd: 15 osds: 15 up (since 33m), 15 in (since 33m) my guess is cephadm wanted 5 managed mons, so did that, but still never removed the removed mon on the removed host. its still up. this is just a vagrant file. so i have two questions. 1. how do you remove that other host and its daemons from the cluster? 2. how would you recover from a host being destroyed? p.s. tried google Your search - "ceph orch host rm" "stray daemons(s) not manage by cephadm" - did not match any documents.

3 years, 9 months

1
1
1 0

Announcing go-ceph v0.5.0

by John Mulligan

I'm happy to announce the another release of the go-ceph API bindings. This is a regular release following our every-two-months release cadence. https://github.com/ceph/go-ceph/releases/tag/v0.5.0 The bindings aim to play a similar role to the "pybind" python bindings in the ceph tree but for the Go language. These API bindings require the use of cgo. There are already a few consumers of this library in the wild, including the ceph-csi project. Specific questions, comments, bugs etc are best directed at our github issues tracker. --- John Mulligan phlogistonjohn(a)asynchrono.us jmulligan(a)redhat.com

3 years, 9 months

1
0
0 0

2024

2023

2022

2021

2020

2019

ceph-users August 2020