Thanks to Anthony D'Atri, Joshua Beaman and Nino Kotur.
TL;DR- I need to ditch the spinning rust.
As long as all my pools are using all the OSDs (currently necessary)
this is not really a tuning problem- just a consequence of adding awful
old recycled disks to my shiny NVME.
To answer a few
Hi,
We are running a ceph cluster that is currently on Luminous. At this
point most of our clients are also Luminous, but as we provision new
client hosts we are using client versions that are more recent (e.g
Octopus, Pacific and more recently Quincy). Is this safe? Is there a
known list of
Rook daily CI is passing against the image
quay.io/ceph/daemon-base:latest-main-devel, which means the Reef release is
looking good from Rook's perspective:
With the Reef release we need to have the tags soon:
quay.io/ceph/daemon-base:latest-reef-devel
quay.io/ceph/ceph:v18
Guillaume, will th
Ok, I restarted it May 25th, ~11:30, let it run over the long weekend and just
checked on it. Data attached.
May 21 11:24:34 cf8 ceph-4e4184f5-7733-453b-b72c-2b43422fd027-osd-183[2282674]:
debug 2023-05-21T18:24:34.040+ 7f53603fc700 0
bluestore(/var/lib/ceph/osd/ceph-183) allocation stats
What kind of pool are you using, or do you have different pools for
different purposes... Do you have cephfs or rbd only pools etc... describe
your setup.
It is generally best practice to create new rules and apply them to pools
and not to modify existing pools, but that is possible as well. Below
On Tue, May 30, 2023 at 6:54 PM Yuri Weinstein wrote:
>
> Details of this release are summarized here:
>
> https://tracker.ceph.com/issues/61515#note-1
> Release Notes - TBD
>
> Seeking approvals/reviews for:
>
> rados - Neha, Radek, Travis, Ernesto, Adam King (we still have to
> merge https://git
On Tue, May 30, 2023 at 8:42 AM Ben wrote:
>
> Hi,
>
> We are performing couple performance tests on CephFS using fio. fio is run
> in k8s pod and 3 pods will be up running mounting the same pvc to CephFS
> volume. Here is command line for random read:
> fio -direct=1 -iodepth=128 -rw=randread -io
Details of this release are summarized here:
https://tracker.ceph.com/issues/61515#note-1
Release Notes - TBD
Seeking approvals/reviews for:
rados - Neha, Radek, Travis, Ernesto, Adam King (we still have to
merge https://github.com/ceph/ceph/pull/51788 for
the core)
rgw - Casey
fs - Venky
orch -
I’m going to start by assuming your pool(s) are deployed with the default 3
replicas and a min_size of 2.
The quickest and safest thing you can do to potentially realize some
improvement, is set the primary-affinity for all of your HDD-based OSDs to zero.
https://docs.ceph.com/en/quincy/rados/op
Hi Marc,
I uploaded all scripts and a rudimentary readme to
https://github.com/frans42/cephfs-bench . I hope it is sufficient to get
started. I'm afraid its very much tailored to our deployment and I can't make
it fully configurable anytime soon. I hope it serves a purpose though - at
least I
Hi folks!
I have a Ceph production 17.2.6 cluster with 6 machines in it - four
newer, faster machines with 4x3.84TB NVME drives each, and two with
24x1.68TB SAS disks each.
I know I should have done something smart with the CRUSH maps for this
up front, but until now I have shied away from C
Hello guys,
What would happen if we set up an RBD mirroring configuration, and in the
target system (the system where the RBD image is mirrored) we create
snapshots of this image? Would that cause some problems?
Also, what happens if we delete the source RBD image? Would that trigger a
deletion in
On Tue, May 30, 2023 at 8:22 AM Tobias Urdin wrote:
>
> Hello Casey,
>
> Thanks for the information!
>
> Can you please confirm that this is only an issue when using
> “rgw_crypt_default_encryption_key”
> config opt that says “testing only” in the documentation [1] to enable
> encryption and not
+1
Michel
Le 30/05/2023 à 11:23, Frank Schilder a écrit :
What I'm having in mind is if the command is already in history. A wrong history
reference can execute a command with "--yes-i-really-mean-it" even though you
really don't mean it. Been there. For an OSD this is maybe tolerable, but fo
Hi,
We are performing couple performance tests on CephFS using fio. fio is run
in k8s pod and 3 pods will be up running mounting the same pvc to CephFS
volume. Here is command line for random read:
fio -direct=1 -iodepth=128 -rw=randread -ioengine=libaio -bs=4k -size=1G
-numjobs=5 -runtime=500 -gr
Hello Casey,
Thanks for the information!
Can you please confirm that this is only an issue when using
“rgw_crypt_default_encryption_key”
config opt that says “testing only” in the documentation [1] to enable
encryption and not when using
Barbican or Vault as KMS or using SSE-C with the S3 API?
What I'm having in mind is if the command is already in history. A wrong
history reference can execute a command with "--yes-i-really-mean-it" even
though you really don't mean it. Been there. For an OSD this is maybe
tolerable, but for an entire cluster ... not really. Some things need to be
h
Hey Frank,
in regards to destroying a cluster, I'd suggest to reuse the old
--yes-i-really-mean-it parameter, as it is already in use by ceph osd
destroy [0]. Then it doesn't matter whether it's prod or not, if you
really mean it ... ;-)
Best regards,
Nico
[0] https://docs.ceph.com/en/latest/r
Hi, I would like to second Nico's comment. What happened to the idea that a
deployment tool should be idempotent? The most natural option would be:
1) start install -> something fails
2) fix problem
3) repeat exact same deploy command -> deployment picks up at current state
(including cleaning u
19 matches
Mail list logo
