Correct, since your OSDs are already created, Ceph won’t do anything.
Maybe think about adding a DB size parameter if you don’t want the
entire disk to be consumed by the existing DBs.
Zitat von Alan Murrell :
Sorry, I just got on this list and am asking a number of questions… ☹
It was sugg
Just keep in mind what it means when you have the failure domain on
OSDs. You’ll probably end up with multiple chunks on the same host,
meaning you’ll have inactive PGs in case that host breaks, or even
only a few participating OSDs. I would recommend such a change only
temporarily.
Zita
Hi Frédéric,
> Can you try the below command?
>
> $ rados -p mailbox listsnaps rbd_data.26f7c5d05af621.2adf
> rbd_data.26f7c5d05af621.2adf:
> cloneid snaps sizeoverlap
> 3 3 4194304 []
> head - 4194304< Do you see this line?
$
See https://tracker.ceph.com/issues/67213
On Wed, Jan 22, 2025 at 9:23 PM Adam Prycki wrote:
> Hi,
>
> today we attempted to upgrade our ceph cluster from 18.2.0 to 18.2.4.
> OSDs updated to 18.2.4 couldn't start.
>
> I've discovered that ceph-osd in segfaults. It happens always on our setup.
>
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Ah, I didn’t notice the release it was for. Sorry ☹ I now know to pay closer
attention to that when I am on the Ceph docs ☹
From: Anthony D'Atri
Sent: February 4, 2025 16:19
To: Anthony D'Atri
Cc: Alan Murrell ; ceph-users@ceph.io
Subject: Re: [ceph-users] Spec file: Possible typo in example:
Now that I’m not on my phone …
Note the URL that you supplied: it specifies the documentation branch for the
Octopus release, which is now EOL. This can happen especially when following
search engine results for a query. This highlights the value in ensuring that
one gets the appropriate doc
Sorry, I just got on this list and am asking a number of questions… ☹
It was suggested in one of my other threads to create and apply a spec file
that would have cephadm put the DB for rotational drives onto SSD when it
creates the OSD on those drives. I came up with he following spec file:
--
The failure domain is part of the CRUSH rule, not the EC profile. One way to
change the failure domain is to decompile, edit, recompile, and inject the
CRUSHmap. Another is to create a new rule via the CLI then assign it to the
desired pool.
> On Feb 4, 2025, at 6:14 PM, Devender Singh wrote
Hello all
Is there a way to change ec pool profile from host to osd?
Regrds
Dev
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Nice catch. I’ll get a fix in.
> On Feb 4, 2025, at 2:10 PM, Alan Murrell wrote:
>
> Hello,
>
> I am not sure if this is the right list to put this, but I was just looking
> over the documentation for the Service Spec file:
>
> https://docs.ceph.com/en/octopus/cephadm/drivegroups/
>
> and u
Hi all,
Many thanks to everyone who has already taken the "Ceph User Stories"
survey, the results of which will be discussed in one of the upcoming
User + Dev Monthly Meetups. See
https://www.meetup.com/ceph-user-group/events/ for updates on upcoming
meetups.
The survey will be closed this week o
Hello,
I am not sure if this is the right list to put this, but I was just looking
over the documentation for the Service Spec file:
https://docs.ceph.com/en/octopus/cephadm/drivegroups/
and under one of the "Advanced Cases" example, I believe there *might* be an
error? Here is the example (f
> I strongly recommend to let cephadm handle the entire process of OSD
> creation, just ensure you have a fitting spec file. Don't prepare any LVs
> manually beforehand, except for such a case as right now where you want to
> move DBs out of the main device.
So if I create a spec file so Ceph a
> You can always fail the mgr (ceph mgr fail) and retry.
I failed the current active mgr (cephnode01) and the secondary took over, but
running the 'ceph orch daemon stop osd.14' still did not work.
Something *seems* to wonky with this OSD< but everything appears healthy. I
even ran a SMART te
> What's the output of
>
> ceph osd ok-to-stop 14
Here it is:
--- START ---
root@cephnode01:/# ceph osd ok-to-stop 14
{"ok_to_stop":true,"osds":[14],"num_ok_pgs":10,"num_not_ok_pgs":0,"ok_become_degraded":["18.0","18.2","18.3","18.f","18.1b","18.26","18.27","18.29","18.2e","18.3a"]}
--- END ---
If your LV is still healthy and you have the space, you could also
just attach a new drive and then pvmove the existing db LVs to the new
drive. That's how we handle our rocksDB SSDs as long as they're still
intact. I'm not entirely sure if you can migrate from one external db
to another, i
One last question/clarification: when it becomes necessary to replace that SSD,
I assume the process of moving the DB/WAL to the new SSD is the same, except in
the 'ceph-volume migrate' command I would specify '--from db' now, yes?
Sent from my mobile device. Please excuse brevity and ttpos.
O
It looks like it works with ceph-volume as well when I remove the LV
before starting the OSD. I just tried that in my lab cluster.
Zitat von Holger Naundorf :
On 04.02.25 12:54, Eugen Block wrote:
Hi Holger,
oh yeah, the noout flag is important of course, I missed that in
this response, a
On 04.02.25 12:54, Eugen Block wrote:
Hi Holger,
oh yeah, the noout flag is important of course, I missed that in this
response, although I mentioned it in the other thread. :-)
-> So is this OSD now using the old LVM device without having the
'block.db' link in its config directory?
No,
On 4/2/25 15:46, Jan Kasprzak wrote:
> I wonder whether is it possible to go the other way round as well,
> i.e. to remove a metadata device from an OSD and merge metadata back
> to the main storage?
Yes.
I actually used ceph-volume last time I did this, so I wonder if I
should be using a cephadm
On Tue, Feb 4, 2025 at 1:40 AM Casey Bodley wrote:
> - future of windows support is uncertain, but we'll keep the windows
> check 'required' as long as it's maintained
That's a surprise.
To what extent can I rely on the future availability of the Windows RBD driver?
--
Alexander Patrakov
_
Hi,
if the daemon is up, marking it down will only have a temporary effect:
mon.nautilus2@0(leader).osd e16065 definitely_dead 0
mon.nautilus2@0(leader).osd e16065 do_prune osdmap full prune enabled
log_channel(cluster) log [WRN] : Health check failed: 1 osds down (OSD_DOWN)
mon.nautilus2@0(lead
Hi Holger,
oh yeah, the noout flag is important of course, I missed that in this
response, although I mentioned it in the other thread. :-)
-> So is this OSD now using the old LVM device without having the
'block.db' link in its config directory?
No, the block.db symlink is most likely st
Hello,
as we are just trying somthing similar i will jump into this as well:
As our initial setup for the WAL/DB was on too small SSDs we need to
move it back to the HDD and replace the SSD with larger ones (and after
that we decide if we just keep it that way - it an archive cluster
without bi
Thank you for the detailed response.
At my primary facility I am already running a five node ceph cluster (among
other server backup servers and GPU stations), so it seems I am already
past the point of benefiting from such a design.
This cluster is currently connected to a Cisco N9K-C92160YC-X,
Hi,
in this case I would recommend to use the ceph-bluestore-tool instead
of ceph-volume because it cleans up (removes the block.db symlink and
labels). These are the steps to revert that change:
# before reverting two devices are in use:
soc9-ceph:~ # ceph osd metadata 0 | grep devices
Thanks, looking into it now.
On Fri, Jan 31, 2025 at 7:55 PM Eugen Block wrote:
> There you go: https://tracker.ceph.com/issues/69755
>
> Let me know if I can provide anything else.
>
> Thanks!
> Eugen
>
> Zitat von Afreen :
>
> > Hi Eugen,
> >
> > We did fix this in squid https://github.com/cep
I'm glad it worked. I thought those steps had already been added to
the docs (cephadm specific), but I couldn't find them either. I'll
ping Zac about it.
Zitat von Alan Murrell :
OK, I think I am good now. I have completed the rest of the steps
(exit shell, start the osd.10 daemon back up
29 matches
Mail list logo
