e{instance_id="a"} 0 ceph_rgw_qactive{instance_id="a"} 0
чт, 20 июн. 2024 г. в 20:09, Anthony D'Atri :
> curl http://endpoint:port/metrics
>
> > On Jun 20, 2024, at 10:15, Peter Razumovsky
> wrote:
> >
> > Hello!
> >
> > I'm using Ceph Reef w
will
appreciate it if someone points us to the full list.
[1]
https://docs.ceph.com/en/latest/mgr/prometheus/#ceph-daemon-performance-counters-metrics
[2] https://docs.ceph.com/en/latest/monitoring/
--
Best regards,
Peter Razumovsky
___
ceph-users
Hello! We're waiting brand new minor 18.2.3 due to
https://github.com/ceph/ceph/pull/56004. Why? Timing in our work is a tough
thing. Could you kindly share an estimation of 18.2.3 release timeframe? It is
16 days passed from original tag creation so I want to understand when it will
be
Hi,
is there a ballpark timeline for a Squid release candidate / release?
I'm aware of this pad that tracks blockers, is that still accurate or should I
be looking at another resource?
https://pad.ceph.com/p/squid-upgrade-failures
Thanks!
peter
st ls". How can it be re-added to
this list?
Thank you,
Peter
BTW full error message:
Inferring fsid ed7b2c16-b053-45e2-a1fe-bf3474f90508
Using ceph image with id '59248721b0c7' and tag 'v17' created on 2024-04-24
16:06:51 + UTC
quay.io/ceph/ceph@sha256:96f2a53bc3028eec16e790c6225e7d7acad8a4
? Is it
possible to do a clean install of the operating system and scan the
existing drives in order to reconstruct the OSD configuration?
Thank you,
Peter
P.S. the cause of the original corruption is likely due to an unplanned
power outage, an event that hopefully will not recur
t all scrubs done. I changed that to 0.01 so it doesn't
bother me now.
Peter
On 2024-03-05 07:58, Anthony D'Atri wrote:
* Try applying the settings to global so that mons/mgrs get them.
* Set your shallow scrub settings back to the default. Shallow scrubs take
very few resources
* Set
> 1. Write object A from client.
> 2. Fsync to primary device completes.
> 3. Ack to client.
> 4. Writes sent to replicas.
[...]
As mentioned in the discussion this proposal is the opposite of
what the current policy, is, which is to wait for all replicas
to be written before writes are
g like this?
[0]
https://docs.ceph.com/en/latest/rados/operations/stretch-mode/#limitations-of-stretch-mode
cheers,
peter.
> Sincerely,
> Vladimir
>
> Get Outlook for Android<https://aka.ms/AAb9ysg>
>
> From: ronny.lipp...@spark5.d
Hi,
this question has come up once in the past[0] afaict, but it was kind of
inconclusive so I'm taking the liberty of bringing it up again.
I'm looking into implementing a key rotation scheme for Ceph client keys. As it
potentially takes some non-zero amount of time to update key material
> [...] After a few days, I have on our OSD nodes around 90MB/s
> read and 70MB/s write while 'ceph -s' have client io as
> 2,5MB/s read and 50MB/s write. [...]
This is one of my pet-peeves: that a storage system must have
capacity (principally IOPS) to handle both a maintenance
workload and a
On 17.01.24 11:13, Tino Todino wrote:
> Hi folks.
>
> I had a quick search but found nothing concrete on this so thought I would
> ask.
>
> We currently have a 4 host CEPH cluster with an NVMe pool (1 OSD per host)
> and an HDD Pool (1 OSD per host). Both OSD's use a separate NVMe for DB/WAL.
>> So we were going to replace a Ceph cluster with some hardware we had
>> laying around using SATA HBAs but I was told that the only right way
>> to build Ceph in 2023 is with direct attach NVMe.
My impression are somewhat different:
* Nowadays it is rather more difficult to find 2.5in SAS or
rbd --version
ceph version 15.2.17 (8a82819d84cf884bd39c17e3236e0632ac146dc4) octopus (stable)
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Thanks for ressponse! Yes, it is in use
"watcher=10.1.254.51:0/1544956346 client.39553300 cookie=140244238214096" this
is indicating the client is connect the image.
I am using fio perform write task on it.
I guess it is the feature not enable correctly or setting somewhere incorrect.
Should I
I follow below document to setup image level rbd persistent cache,
however I get error output while i using the command provide by the document.
I have put my commands and descriptions below.
Can anyone give some instructions? thanks in advance.
:13
To: Peter
Cc: ceph-users@ceph.io
Subject: Re: [ceph-users] Assistance Needed with Ceph Cluster Slow Ops Issue
Hi Peter,
try to set the cluster to nosnaptrim
If this helps, you might need to upgrade to pacific, because you are hit by the
pg dups bug.
See: https://www.clyso.com/blog/how
Dear all,
I am reaching out regarding an issue with our Ceph cluster that has been
recurring every six hours. Upon investigating the problem using the "ceph
daemon dump_historic_slow_ops" command, I observed that the issue appears to be
related to slow operations, specifically getting stuck
> the speed of data transfer is varying a lot over time (200KB/s
> – 120MB/s). [...] The FS in question, has a lot of small files
> in it and I suspect this is the cause of the variability – ie,
> the transfer of many small files will be more impacted by
> greater site-site latency.
200KB/s on
>>> during scrubbing, OSD latency spikes to 300-600 ms,
>> I have seen Ceph clusters spike to several seconds per IO
>> operation as they were designed for the same goals.
>>> resulting in sluggish performance for all VMs. Additionally,
>>> some OSDs fail during the scrubbing process.
>> Most
> during scrubbing, OSD latency spikes to 300-600 ms,
I have seen Ceph clusters spike to several seconds per IO
operation as they were designed for the same goals.
> resulting in sluggish performance for all VMs. Additionally,
> some OSDs fail during the scrubbing process.
Most likely they time
This server configured Dell R730 with HBA 330 card HDD are configured write
through mode.
From: David C.
Sent: Wednesday, November 8, 2023 10:14
To: Peter
Cc: ceph-users@ceph.io
Subject: Re: [ceph-users] HDD cache
Without (raid/jbod) controller ?
Le mer. 8
Hi All,
I note that HDD cluster commit delay improves after i turn off HDD cache.
However, i also note that not all HDDs are able to turn off the cache. special
I found that two HDD with same model number, one can turn off, anther doesn't.
i guess i have my system config or something different
> [...] (>10k OSDs, >60 PB of data).
6TBs on average per OSD? Hopully SSDs or RAID10 (or low-number,
3-5) RAID5.
> It is entirely dedicated to object storage with S3 interface.
> Maintenance and its extension are getting more and more
> problematic and time consuming.
Ah the joys of a single
> * Ceph cluster with old nodes having 6TB HDDs
> * Add new node with new 12TB HDDs
Halving IOPS-per-TB?
https://www.sabi.co.uk/blog/17-one.html?170610#170610
https://www.sabi.co.uk/blog/15-one.html?150329#150329
> Is it supported/recommended to pack 2 6TB HDDs handled by 2
> old OSDs into 1
[...]
> What is being done is a serial tree walk and copy in 3
> replicas of all objects in the CephFS metadata pool, so it
> depends on both the read and write IOPS rate for the metadata
> pools, but mostly in the write IOPS. [...] Wild guess:
> metadata is on 10x 3.84TB SSDs without persistent
>> However, I've observed that the cephfs-data-scan scan_links step has
>> been running for over 24 hours on 35 TB of data, which is replicated
>> across 3 OSDs, resulting in more than 100 TB of raw data.
What matters is the number of "inodes" (and secondarily their
size), that is the number of
>> However, I've observed that the cephfs-data-scan scan_links step has
>> been running for over 24 hours on 35 TB of data, which is replicated
>> across 3 OSDs, resulting in more than 100 TB of raw data.
What matters is the number of "inodes" (and secondarily their
size), that is the number of
more. Instead it looks like something that over time broke
with ext4.
Sending this to the list in case someone else has a similar problem in
the future.
/Peter
Den 2023-09-29 kl. 19:02, skrev peter.lin...@fiberdirekt.se:
Yes, this is all set up. It was working fine until after the problem
this one that cant overwrite.
I'm thinking there is somehow something wrong with just this image?
Regards,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Hi Matthias,
One possible way to achieve your need is to set a quota on number of
buckets at user level (see
https://docs.ceph.com/en/reef/radosgw/admin/#quota-management). Quotas are
under admin control.
Rgds,
Peter
Le dim. 1 oct. 2023, 10:51, Matthias Ferdinand a
écrit :
> Hi,
>
d",
"release": "luminous",
"num": 12
}
],
"mgr": [
{
"features": "0x3f01cfbf7ffd",
"release": "luminous",
"num":
{
"features": "0x3f01cfb87fec",
"release": "luminous",
"num": 4
},
{
"features": "0x3f01cfbf7ffd",
"release": "luminous",
this one that cant overwrite.
I'm thinking there is somehow something wrong with just this image?
Regards,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
to other commands (especially the ones sent by the liveness probe).
Default liveness probe timeout setup by rook is probably too small in
regards of device_health_check duration.
In our case, we disabled device_health_check on mgr side.
Rgds,
Peter
Le jeu. 21 sept. 2023 à 21:35, Sudhin Bengeri
Hi Ceph community,
My cluster has lots of logs regarding an error that ceph-osd. I am
encountering the following error message in the logs:
Aug 22 00:01:28 host008 ceph-osd[3877022]: 2023-08-22T00:01:28.347-0700
7fef85251700 -1 Fail to open '/proc/3850681/cmdline' error = (2) No such file
> We recently started experimenting with Proxmox Backup Server,
> which is really cool, but performs enough IO to basically lock
> out the VM being backed up, leading to IO timeouts, leading to
> user complaints. :-(
The two most common things I have had to fix over years as to
storage systems I
,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
[...] S3 workload, that will need to delete 100M file
daily [...]
>> [...] average (what about peaks?) around 1,200 committed
>> deletions per second (across the traditional 3 metadata
>> OSDs) sustained, that may not leave a lot of time for file
> creation, writing or reading. :-)[...]
>>> On Mon, 17 Jul 2023 19:19:34 +0700, Ha Nguyen Van
>>> said:
> [...] S3 workload, that will need to delete 100M file daily [...]
So many people seem to think that distributed (or even local)
filesystems (and in particular their metadata servers) can
sustain the same workload as high volume
>>> On Wed, 17 May 2023 16:52:28 -0500, Harry G Coin
>>> said:
> I have two autofs entries that mount the same cephfs file
> system to two different mountpoints. Accessing the first of
> the two fails with 'stale file handle'. The second works
> normally. [...]
Something pretty close to that
> [...] We have this slow and limited delete issue also. [...]
That usually, apart from command list length limitations,
happens because so many Ceph storage backends have too low
committed IOPS (write, but not just) for mass metadata (and
equivalently small data) operations, never mind for
},
"rocksdb": {
"get": 769,
"submit_transaction": 18292538,
"submit_transaction_sync": 13561020,
"get_latency": {
"avgcount": 769,
"sum": 739.658957592,
&quo
:58.070854+0800
pg 4.7a4 not scrubbed since 2023-04-24T02:55:25.912789+0800
pg 4.7b4 not scrubbed since 2023-04-24T10:04:46.889422+0800
pg 4.7c8 not scrubbed since 2023-04-24T13:36:07.284271+0800
pg 4.7d2 not scrubbed since 2023-04-24T14:47:19.365551+0800
Peter
Hi Emmaneul
It was a while ago, but as I recall I evicted all clients and that allowed
me to restart the MDS servers. There was something clearly "broken" in how
at least one of the clients was interacting with the system.
Peter
On Thu, 4 May 2023 at 07:18, Emmanuel Jaep wrote:
>
limit the UDP triggering
and resolve the "corosync" issue.
I appreciate your help in this matter and look forward to your response.
Peter
-Original Message-
From: Fabian Grünbichler
Sent: Wednesday, April 26, 2023 12:42 AM
To: ceph-users@ceph.io; Peter
Subject: Re: [ceph-users
On a 38 TB cluster, if you scrub 8 MB/s on 10 disks (using only numbers
already divided by replication factor), you need 55 days to scrub it once.
That's 8x larger than the default scrub factor [...] Also, even if I set
the default scrub interval to 8x larger, it my disks will still be thrashing
> On a 38 TB cluster, if you scrub 8 MB/s on 10 disks (using only
> numbers already divided by replication factor), you need 55 days
> to scrub it once.
> That's 8x larger than the default scrub factor [...] Also, even
> if I set the default scrub interval to 8x larger, it my disks
> will still
> On a 38 TB cluster, if you scrub 8 MB/s on 10 disks (using only
> numbers already divided by replication factor), you need 55 days
> to scrub it once.
> That's 8x larger than the default scrub factor [...] Also, even
> if I set the default scrub interval to 8x larger, it my disks
> will still
Dear all,
We are experiencing with Ceph after deploying it by PVE with the network backed
by a 10G Cisco switch with VPC feature on. We are encountering a slow OSD
heartbeat and have not been able to identify any network traffic issues.
Upon checking, we found that the ping is around 0.1ms,
I am trying to do this, but the log file is 26 GB and growing. Is there
perhaps a subset of the logs that would be useful?
Peter
On Mon, 16 Jan 2023 at 18:42, wrote:
> Hi Peter,
>
> Could you add debug_bluestore = 20 to your ceph.conf and restart the OSD,
> then send the log afte
the
daemons solved the problem.
Peter
On Thu, 9 Feb 2023 at 16:27, Tarrago, Eli (RIS-BCT) <
eli.tarr...@lexisnexisrisk.com> wrote:
> Please include your promtai; logs, loki logs, promtail configuration, and
> your loki configuration.
>
>
>
> *From: *Peter van Heus
daemons are running on each node including the OSDs. The Loki
server and Grafana are running on one of our monitor nodes.
Thanks for any clarifications you can provide.
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email
st
and rebuild them?
Thanks,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Thanks. The command definitely shows "slow_bytes":
"db_total_bytes": 1073733632,
"db_used_bytes": 240123904,
"slow_total_bytes": 4000681103360,
"slow_used_bytes": 8355381248,
So I am not sure why the warnings ar
is
despite bluestore_warn_on_bluefs_spillover still being set to true.
Is there a way to investigate the current state of the DB to see if
spillover is, indeed, still happening?
Thank you,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an ema
up must have a non-empty name
This host is the only one which has 14 drives which aren't being used. I'm
guessing this is why its getting this error. The drives may have been used
previous in a cluster (maybe not the same cluster) or something. I don't know.
Any suggestions for what to try to
Am 21.07.22 um 17:50 schrieb Ilya Dryomov:
On Thu, Jul 21, 2022 at 11:42 AM Peter Lieven wrote:
Am 19.07.22 um 17:57 schrieb Ilya Dryomov:
On Tue, Jul 19, 2022 at 5:10 PM Peter Lieven wrote:
Am 24.06.22 um 16:13 schrieb Peter Lieven:
Am 23.06.22 um 12:59 schrieb Ilya Dryomov:
On Thu, Jun
Am 21.07.22 um 17:50 schrieb Ilya Dryomov:
> On Thu, Jul 21, 2022 at 11:42 AM Peter Lieven wrote:
>> Am 19.07.22 um 17:57 schrieb Ilya Dryomov:
>>> On Tue, Jul 19, 2022 at 5:10 PM Peter Lieven wrote:
>>>> Am 24.06.22 um 16:13 schrieb Peter Lieven:
>>>>&
Am 19.07.22 um 17:57 schrieb Ilya Dryomov:
On Tue, Jul 19, 2022 at 5:10 PM Peter Lieven wrote:
Am 24.06.22 um 16:13 schrieb Peter Lieven:
Am 23.06.22 um 12:59 schrieb Ilya Dryomov:
On Thu, Jun 23, 2022 at 11:32 AM Peter Lieven wrote:
Am 22.06.22 um 15:46 schrieb Josh Baergen:
Hey Peter
Am 24.06.22 um 16:13 schrieb Peter Lieven:
Am 23.06.22 um 12:59 schrieb Ilya Dryomov:
On Thu, Jun 23, 2022 at 11:32 AM Peter Lieven wrote:
Am 22.06.22 um 15:46 schrieb Josh Baergen:
Hey Peter,
I found relatively large allocations in the qemu smaps and checked the
contents. It contained
Am 23.06.22 um 12:59 schrieb Ilya Dryomov:
> On Thu, Jun 23, 2022 at 11:32 AM Peter Lieven wrote:
>> Am 22.06.22 um 15:46 schrieb Josh Baergen:
>>> Hey Peter,
>>>
>>>> I found relatively large allocations in the qemu smaps and checked the
>>>>
Am 23.06.22 um 12:59 schrieb Ilya Dryomov:
On Thu, Jun 23, 2022 at 11:32 AM Peter Lieven wrote:
Am 22.06.22 um 15:46 schrieb Josh Baergen:
Hey Peter,
I found relatively large allocations in the qemu smaps and checked the
contents. It contained several hundred repetitions of osd and pool
Am 22.06.22 um 15:46 schrieb Josh Baergen:
Hey Peter,
I found relatively large allocations in the qemu smaps and checked the
contents. It contained several hundred repetitions of osd and pool names. We
use the default builds on Ubuntu 20.04. Is there a special memory allocator in
place
> Am 22.06.2022 um 14:28 schrieb Ilya Dryomov :
>
> On Wed, Jun 22, 2022 at 11:14 AM Peter Lieven wrote:
>>
>>
>>
>> Von meinem iPhone gesendet
>>
>>>> Am 22.06.2022 um 10:35 schrieb Ilya Dryomov :
>>>
>>&g
s far as I know there is no special allocator on place so I wonder why there
are so big allocations.
Peter
>
> --
> May the most significant bit of your life be positive.
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Von meinem iPhone gesendet
> Am 22.06.2022 um 10:35 schrieb Ilya Dryomov :
>
> On Tue, Jun 21, 2022 at 8:52 PM Peter Lieven wrote:
>>
>> Hi,
>>
>>
>> we noticed that some of our long running VMs (1 year without migration) seem
>> t
for a very small dev cluster with approx. 40 OSDs and 5 pools.
We have observed this issue first with Nautilus 14.2.22 and then also tried
Octopus 15.2.16 where some issues #38403 should have been fixed.
Any ideas except from migrating VMs when PSS usage gets too high?
Thanks
Peter
ble starts installing sandbox containers and
things on a monitor which only exists to be a mon/mgr host after running this
successfully:
ansible-playbook infrastructure-playbooks/add-mon.yml --limit cephmon-t03
Any advice?
peter
Peter Eisch
Senior Site Reliability Engineer
peter.ei...@virgi
,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
n't track the number of
stand bys you might end up with 0 managers in the end...
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
we have never seen it
before 14.2.22.
Maybe it broke things.
Our workaround (which works so far) is to disable the prometheus module and use
Digital Ocean Ceph Exporter.
https://github.com/digitalocean/ceph_exporter
Best,
Peter
>
> 2022-01-13 13:15:59.330 7fe7e085e700 -1
ster elects another mgr as
primary, but
the original primary does not recover. The process is stuck. I have a (large)
backtrace if someone is interested.
For us it seems that the prometheus exporter module is the cause. Do you have
it enabled?
Peter
___
client and it works as expected. With
Octopus 15.2.12 I can reproduce the issue.
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
still
>> at 1% for our use.
>
> Thanks, that's really useful to know.
Whatever SSD you choose, look if they support power-loss-protection and make
sure you disable the write cache.
Peter
___
ceph-users mailing list -- ceph-users@ce
is transferred unencrypted over the wire.
RBD encryption takes place in the client.
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
use the
latest N release with very few additional fixes. If the people longing for an
LTS release mainly are those who are
using Ceph as VM Storage, we could use this as a basis.
Thanks,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Am 17.11.21 um 12:20 schrieb Igor Fedotov:
> Hi Peter,
>
> sure, why not...
See [1]. I read it that it is not wanted by upstream developers. If we want it
the community has to do it.
Nevertheless, I have put it on the list.
Peter
[1]
https://lists.ceph.io/hyperkitty/list/d..
s://pad.ceph.com/p/ceph-user-dev-monthly-minutes
>
> Any volunteers to extend the agenda and advocate the idea?
Hi Igor,
do you still think we can add the LTS topic to the agenda? I will attend
tomorrow and can try to advocate it.
Best,
Peter
>
> Thanks,
> Igor
>
>>
ack a switch for all those who don't
require the read lease feature and are happy with reading from just the primary?
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
ebug this and finally I
> missed only one step in the upgrade.
>
> Only during the update itself, until require_osd_release is set to the new
> version, there will be interruptions
However, in Octopus the issue does still exist, right?
Peter
__
r because they are just working too good.
Best,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
ted at the point where the osd compat level is set to
octopus.
So one of my initial guesses back when I tried to analyze this issue was that
it has something to do with the new "read from all osds not just the primary"
feature.
Makes that sense?
Best,
Peter
__
n process can take more time than a
peer OSD getting ECONNREFUSED. The combination above is the recommended
combation (and the default).
When we fast this issue we had a fresh Octopus install with default values...
If necessary I can upgrade our development cluster to Octopus again
Hi Istvan,
I have not given Octopus another try yet. But as far as I remember Manuel
figured out the root cause.
Maybe he can give more insights.
Best,
Peter
Am 28.10.21 um 13:07 schrieb Szabo, Istvan (Agoda):
Hi Peter,
Have you figured out what was the issue?
Istvan Szabo
Senior
On 22.10.21 11:29, Mevludin Blazevic wrote:
> Dear Ceph users,
>
> I have a small Ceph cluster where each host consist of a small amount of SSDs
> and a larger number of HDDs. Is there a way to use the SSDs as performance
> optimization such as putting OSD Journals to the SSDs and/or using SSDs
ning. To get fast
>preprovisioning you need Octopus (available) and an updated QEMU driver (not
>yet available).
I have recently made several improvements to the Qemu driver and if there is
need for it I can look into preprovisioning suppo
> Am 22.10.2021 um 11:12 schrieb Tommy Sway :
>
> Even hypervisor support is useless if ceph itself does not support it.
Thick provisioning is supported from Octopus onwards. If you are using Qemu I
can look into adding support for preprovisioning in the Qemu drive
Am 01.10.21 um 16:52 schrieb Josh Baergen:
Hi Peter,
When I check for circles I found that running the upmap balancer alone never
seems to create
any kind of circle in the graph
By a circle, do you mean something like this?
pg 1.a: 1->2 (upmap to put a chunk on 2 instead of 1)
pg 1.b: 2
be a nice addition to pgremapper to add an option to optimze the upmap
table. When searching for circles you might want to limit
the depth of the DFS otherwise the runtime will be crazy.
Thanks,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
upmap for a pg from OSD A to OSD B and
an upmap for another pg from OSB B to OSD A
whereas it would just be enough to have no upmap at all.
Thanks,
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
performance penalty.
sdparm --clear WCE /dev/sdX
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
) [0x7f3c62a7fbe3]
7: (EventCenter::process_events(unsigned int, std::chrono::duration >*)+0xd57) [0x7f3c62ad4ae7]
8: (()+0x61c1d8) [0x7f3c62ad91d8]
9: (()+0x8fa4af) [0x7f3c62db74af]
10: (()+0x76ba) [0x7f3c6c33a6ba]
11: (clone()+0x6d) [0x7f3c6c0705
for osd_op_queue_cut_off was set to low by mistake prior to
Octopus.
Peter
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
Have you tried setting
osd op queue cut off to high?
Peter
> Am 11.08.2021 um 15:24 schrieb Frank Schilder :
>
> The recovery_sleep options are the next choice to look at. Increase it and
> clients will get more I/O time slots. However, with your settings, I'm
> su
) and CentOs 8 does not support the hardware
I've got (the disks are not detected, and I can't find the right
drivers)
I suspect I've not got to do some tidying up before I continue but this
does look smoother than when I tried with 16.2.0, which was 4 months ago.
Thanks
Peter.
On Fri, 6 Aug 2021
12a34-osd.conf'
The good news this is a pre-production proof of concept cluster still so
I'm attempting to iron out issues, before we try and make it a production
service.
Any ideas would be helpful.
I guess deploy might be an option but that does not feel very future proof.
Thanks
Peter Childs
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
a ticket.
Peter
On Fri, 6 Aug 2021 at 10:00, Yann Dupont wrote:
>
> Le 28/06/2021 à 10:52, Peter van Heusden a écrit :
> > I am running Ceph 15.2.13 on CentOS 7.9.2009 and recently my MDS servers
> > have started failing with the error message
> >
> > In function 'v
switch
multipath off the disks work, but I'd only get half the bandwidth. (Oh and
ceph will get confused as it can see each drive twice).
Thanks.
Peter.
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le
to look for the problems rather than any
exact answers, I'm yet to see any clues that might help
Thanks in advance
Peter Childs
___
ceph-users mailing list -- ceph-users@ceph.io
To unsubscribe send an email to ceph-users-le...@ceph.io
1 - 100 of 164 matches
Mail list logo
