I'm having a problem setting up a cluster after we gave up on nautilus with a
number of operational problems and decided to downgrade back to what we've been
using. I have been able to install the servers running centos, but the 3 that
run the osds are all on RHEL7.7 and the odd thing is that I
If only it were that easy…
$ sudo yum remove librados* -y
Loaded plugins: langpacks, priorities, product-id, search-disabled-repos,
subscription-manager
No Match for argument: librados*
No Packages marked for removal
[cephuser@storsvr2 ~]$ sudo yum install libradosstriper-12.2.9 -y
Loaded plugins
Hi,
Please find the ceph osd tree output in the pastebin
https://pastebin.com/Gn93rE6w
On Fri, Nov 8, 2019 at 7:58 PM huang jun wrote:
> can you post your 'ceph osd tree' in pastebin?
> do you mean the osds report fsid mismatch is from old removed nodes?
>
> nokia ceph 于2019年11月8日周五 下午10:21写道：
The mon log shows that the all mismatch fsid osds are from node 10.50.11.45,
maybe that the fith node?
BTW i don't found the osd.0 boot message in ceph-mon.log
do you set debug_mon=20 first and then restart osd.0 process, and make
sure the osd.0 is restarted.
nokia ceph 于2019年11月10日周日 下午12:31写道：
Hi Huang,
Yes the node 10.50.10.45 is the fifth node which is replaced. Yes I have
set the debug_mon to 20 and still it is running with that value only. If
you want I will send you the logs of the mon once again by restarting the
osd.0
On Sun, Nov 10, 2019 at 10:17 AM huang jun wrote:
> The mon
good, please send me the mon and osd.0 log.
the cluster still un-recovered?
nokia ceph 于2019年11月10日周日 下午1:24写道：
>
> Hi Huang,
>
> Yes the node 10.50.10.45 is the fifth node which is replaced. Yes I have set
> the debug_mon to 20 and still it is running with that value only. If you want
> I will
Zap had an issue back then and never properly worked, you have to manually dd,
we always played it save and went 2-4GB in just to be sure.Should fix your
issue.
___
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/cep
This only happens with this one specific node?checked system logs? checked
SMART on all disks?I mean technically it's expected to have slower writes when
the third node is there, it's by ceph design.
___
ceph-users mailing list
ceph-users@lists.ceph.com
Hi,
yes still the cluster unrecovered. Not able to even up the osd.0 yet.
osd logs: https://pastebin.com/4WrpgrH5
Mon logs: https://drive.google.com/open?id=1_HqK2d52Cgaps203WnZ0mCfvxdcjcBoE
# ceph daemon /var/run/ceph/ceph-mon.cn1.asok config show|grep debug_mon
"debug_mon": "20/20",
"
The same problem:
2019-11-10 05:26:33.215 7fbfafeef700 7 mon.cn1@0(leader).osd e1819
preprocess_boot from osd.0 v2:10.50.11.41:6814/2022032 clashes with
existing osd: different fsid (ours:
ccfdbd54-fcd2-467f-ab7b-c152b7e422fb ; theirs: a1ea2ea3-984d
-4c91-86cf-29f452f5a952)
maybe the osd uuid is w
10 matches
Mail list logo
