This is to announce the retirement of v13.2.X Mimic stable release
series, and there will no longer be any more backport releases to the
Mimic series. Any more patches to the mimic branch will have to be
tested by the developer submitting the patches and approved by the tech
lead of the respective component before merge to keep the branch stable.
The last release of Mimic was v13.2.10 released on Apr 2020. This is
keeping up with the active 2 stable releases and 24 month support cycle,
which is documented at
https://docs.ceph.com/docs/master/releases/general/#lifetime-of-stable-rele…
Users are requested to upgrade to Nautilus or Octopus.
For the official blog post link please refer to
https://ceph.io/releases/mimic-is-retired/
--
Abhishek Lekshmanan
SUSE Software Solutions Germany GmbH
GF: Felix Imendörffer, HRB 36809 (AG Nürnberg)
Hi,
I am trying to profile the number of invocations to a particular function
in Ceph source code. I have instrumented the code with time functions.
Can someone please share the script for compiling and running the Ceph
source code? I am struggling with it. That would be great help !
BR
Bobby !
There is a general documentation meeting called the "DocuBetter Meeting",
and it is held every two weeks. The next DocuBetter Meeting will be on July
22, 2020 at 1800 PST, and will run for thirty minutes. Everyone with a
documentation-related request or complaint is invited. The meeting will be
held here: https://bluejeans.com/908675367
This meeting will be more substantial than many of the recent meetings,
because the reorganization of the docs.ceph.com website will be discussed
at it.
Send documentation-related requests and complaints to me by replying to
this email and CCing me at zac.dover(a)gmail.com.
This message will be sent to dev(a)ceph.io Monday morning, North American
time.
The next DocuBetter meeting is scheduled for:
22 Jul 2020 1800 PST
23 Jul 2020 0100 UTC
23 Jul 2020 1100 AEST
Etherpad: https://pad.ceph.com/p/Ceph_Documentation
Meeting: https://bluejeans.com/908675367
Thanks, everyone.
Zac Dover
Hello everyone,
I m building my ceph project, with steps
1.git submodule update --init --recursive
2. sudo ./make-debs.sh
while running the second command I get error in debian control file at line
850 unknow format (not field-colon-value). I saw online that it is a
indentation error but I cant seem to find the error in my files.
My debian/control file
https://github.com/suab321321/ceph/blob/master/debian/control
Hi,
I have a question regarding support for multiple BLK-MQ queues for Ceph's
RADOS Block Device (RBD). The below given link says that the driver has
been using the BLK-MQ interface for a while but not actually multiple
queues until now with having a queue per-CPU. A change to not hold onto
caps that aren't actually needed. These improvements and more can be found
as part of the Ceph changes for Linux 5.7, which should be released as
stable in early June.
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.7-Ceph-Performa…
My question is: Is it possible that through Ceph FS (Filesystem in User
Space) I can develop a multi-queue driver for Ceph? Asking because this way
I can avoid kernel space. (
https://docs.ceph.com/docs/nautilus/start/quick-cephfs/)
Looking forward for some help
BR
Bobby
Hi Folks,
The weekly performance meeting will be starting in ~15 minutes. I
wasn't able to get slides for the IO500 testing done so I'm punting that
presentation for a future meeting. That's ok though, because we've got
a lot to talk about regarding encode/decode, memory pools, and bluestore
collection list performance issues! See you there!
Etherpad:
https://pad.ceph.com/p/performance_weekly
Bluejeans:
https://bluejeans.com/908675367
Thanks,
Mark
On Wed, Jul 15, 2020 at 1:41 PM Budai Laszlo <laszlo.budai(a)gmail.com> wrote:
>
> Hi Bobby,
>
> Thank you for your answer. You are saying "Whenever there is a change in the map, the monitor will inform the client." Can you please give me some ceph documentation link where I could read these details? For me it is logical to have the monitors update the clients about changes in the cluster map. I'm looking for the details of this process. Like how does the monitor knows which clients to update?
Clients subscribe to map updates, either continuous or one-time.
The monitor keeps track of clients that asked for continuous updates
and whenever a new map of the respective type is published, sends
it to those clients (for osdmaps, what gets sent is an incremental
on top of the previous osdmap as the full osdmap can be quite large).
Most clients don't subscribe to continuous map updates and instead
rely on lazy map propagation. When an OSD receives a request from
a client with an old osdmap, it will send an incremental along with
the reply (or instead of the reply, if, according to the current
osdmap, the request should have been directed to a different OSD).
The client processes the incremental and resends the request if
needed.
Thanks,
Ilya
Hi Budai,
When you ask "*how often the client is retrieving the Cluster Map?*" . The
obvious answer to that is there is nothing 'often' in it. Whenever there is
a change in the map, the monitor will inform the client.
I think you need to read about the CRUSH algorithm in Ceph. Because that
will explain you the map changes and data movement. While going through
CRUSH, forget there is a monitor node. Just suppose there is a client
machine and this client machine READ/WRITE to a cluster ( number of OSDs).
Because theoretically a Ceph client can also be a monitor (not at all
recommended for practical purposes). Once you have understood CRUSH, I am
quite sure that will answer many of your questions.
And feel free to ask about CRUSH. I would be glad to answer.
BR
On Wed, Jul 15, 2020 at 8:54 AM Budai Laszlo <laszlo.budai(a)gmail.com> wrote:
>
> to be more specific: if we have an RBD volume used by a client (a
> hypervisor, or or mapped with rbd), we assume continuous activity on the
> volume. How often will the RBD client contact the monitor to get the
> current map? Are you aware of any documentation page that describes this
> interaction?
>
> Thank you,
> Laszlo
>
>
> On 7/15/20 8:12 AM, Budai Laszlo wrote:
> > Hi Nghia,
> >
> > in the docs (https://docs.ceph.com/docs/master/architecture/#about-pools)
> there is the statement "Ceph Clients retrieve a Cluster Map from a Ceph
> Monitor, and write objects to pools." My question is how often the client
> is retrieving the Cluster Map? How does the client get the knowledge about
> a change in the cluster?
> >
> > Thank you,
> > Laszlo
> >
> > On 7/15/20 7:57 AM, Nghia Viet Tran wrote:
> >> Hi Laszlo,
> >>
> >> Which client are you talking about?
> >>
> >> On 7/15/20, 11:54, "Budai Laszlo" <laszlo.budai(a)gmail.com> wrote:
> >>
> >> Hello everybody,
> >>
> >> I'm trying to figure out how often the ceph client is contacting
> the monitors for updating its own information about the cluster map.
> >> Can anyone point me to a document describing this client <->
> monitor communication?
> >>
> >> Thank you,
> >> Laszlo
> >> _______________________________________________
> >> ceph-users mailing list -- ceph-users(a)ceph.io
> >> To unsubscribe send an email to ceph-users-leave(a)ceph.io
> >>
> >
> _______________________________________________
> ceph-users mailing list -- ceph-users(a)ceph.io
> To unsubscribe send an email to ceph-users-leave(a)ceph.io
>
