Hi,
AFAIk SD cards (and SATA DOMs) do not have any kind of wear-leveling
support. Even if the crappy write endurance of these storage systems
would be enough to operate a server for several years on average, you
will always have some hot spots with higher than usual write activity.
This is t
On Mon, Aug 13, 2018 at 9:55 PM Zhenshi Zhou wrote:
>
> Hi Burkhard,
> I'm sure the user has permission to read and write. Besides, we're not using
> EC data pools.
> Now the situation is that any openration to a specific file, the command will
> hang.
> Operations to any other files won't hang.
kernel client
Yan, Zheng 于2018年8月14日周二 下午3:13写道：
> On Mon, Aug 13, 2018 at 9:55 PM Zhenshi Zhou wrote:
> >
> > Hi Burkhard,
> > I'm sure the user has permission to read and write. Besides, we're not
> using EC data pools.
> > Now the situation is that any openration to a specific file, the comm
Hello Jason,
I can confirm that your tests work on our cluster with a newly created image.
We still can’t get the current images to use a different object pool. Do you
think that maybe another feature is incompatible with this feature? Below is a
log of the issue.
:~# rbd info RBD_HDD/2ef34a9
Hi all,
we're running Ceph Jewel 10.2.10 in our cluster and we plan to upgrade
to latest Luminous
release(12.2.7). Jewel 10.2.11 was released one month ago and ours plans
were upgrade to
this release first and then upgrade to Luminous, but as someone reported
osd's crashes after
upgradin
Hi all,
we're running Ceph Jewel 10.2.10 in our cluster and we plan to upgrade to
latest Luminous
release(12.2.7). Jewel 10.2.11 was released one month ago and ours plans were
upgrade to
this release first and then upgrade to Luminous, but as someone reported osd's
crashes after
upgrading to
Hello All!
I am using mimic full bluestore cluster with pure RGW workload. We use AWS
i3 instance family for osd machines - each instance has 1 NVMe disk which
is split into 4 partitions and each of those partitions is devoted to
bluestore block device. We use 1 device per partition - so everythin
IIRC this will create a rule that tries to selects n independent data
centers
Check the actual generated rule to validate this.
I think the only way to express "3 copies across two data centers" is by
explicitly
using the two data centers in the rule as in:
(pseudo code)
take dc1
chooseleaf 1 typ
We have configured cephfs .
Yes i can restore the data. But i need to know which files are corrupted.
So that i can delete those files and copy them again.
In normal state i can get inode id of files and mapping inode id with
object id. So that i can get files to object mapping . using ceph osd ma
Thanks for suggestion about restarting OSD's, but this doesn't work either.
Anyway, I managed to fix second unrepairing PG by getting object from OSD
and saving it again via rados, but still no luck with first one.
I think, I found main problem why this doesn't work. Seems, object is not
overwritt
On Tue, Aug 14, 2018 at 4:08 AM Glen Baars
wrote:
> Hello Jason,
>
>
>
> I can confirm that your tests work on our cluster with a newly created
> image.
>
>
>
> We still can’t get the current images to use a different object pool. Do
> you think that maybe another feature is incompatible with thi
Hello Jason,
I will also complete testing of a few combinations tomorrow to try and isolate
the issue now that we can get it to work with a new image.
The cluster started out at 12.2.3 bluestore so there shouldn’t be any old
issues from previous versions.
Kind regards,
Glen Baars
From: Jason D
On Mon, Aug 13, 2018 at 5:57 PM Nikola Ciprich
wrote:
>
> Hi Ilya,
>
> hmm, OK, I'm not sure now whether this is the bug which I'm
> experiencing.. I've had read_partial_message / bad crc/signature
> problem occurance on the second cluster in short period even though
> we're on the same ceph ver
> > Hi Ilya,
> >
> > hmm, OK, I'm not sure now whether this is the bug which I'm
> > experiencing.. I've had read_partial_message / bad crc/signature
> > problem occurance on the second cluster in short period even though
> > we're on the same ceph version (12.2.5) for quite long time (almost sin
I tried w/ a rbd CLI from 12.2.7 and I still don't have an issue enabling
journaling on a different pool:
$ rbd info rbd/foo
rbd image 'foo':
size 1024 MB in 256 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.101e6b8b4567
format: 2
features: layering, exclusive-lock, object-map, fa
Hello Jason,
I have tried with and without ‘rbd journal pool = rbd’ in the ceph.conf. it
doesn’t seem to make a difference.
Also, here is the output:
rbd image-meta list RBD-HDD/2ef34a96-27e0-4ae7-9888-fd33c38f657a
There are 0 metadata on this image.
Kind regards,
Glen Baars
From: Jason Dillam
On Tue, Aug 14, 2018 at 9:19 AM Glen Baars
wrote:
> Hello Jason,
>
>
>
> I have tried with and without ‘rbd journal pool = rbd’ in the ceph.conf.
> it doesn’t seem to make a difference.
>
It should be SSDPOOL, but regardless, I am at a loss as to why it's not
working for you. You can try appendi
Hello Jason,
I have now narrowed it down.
If the image has an exclusive lock – the journal doesn’t go on the correct pool.
Kind regards,
Glen Baars
From: Jason Dillaman
Sent: Tuesday, 14 August 2018 9:29 PM
To: Glen Baars
Cc: ceph-users
Subject: Re: [ceph-users] RBD journal feature
On Tue,
On Tue, Aug 14, 2018 at 9:31 AM Glen Baars
wrote:
> Hello Jason,
>
>
>
> I have now narrowed it down.
>
>
>
> If the image has an exclusive lock – the journal doesn’t go on the correct
> pool.
>
OK, that makes sense. If you have an active client on the image holding the
lock, the request to enab
Hello Jason,
Thanks for your help. Here is the output you asked for also.
https://pastebin.com/dKH6mpwk
Kind regards,
Glen Baars
From: Jason Dillaman
Sent: Tuesday, 14 August 2018 9:33 PM
To: Glen Baars
Cc: ceph-users
Subject: Re: [ceph-users] RBD journal feature
On Tue, Aug 14, 2018 at 9:31
Le 13/08/2018 à 16:58, Jason Dillaman a écrit :
>
> See [1] for ways to tweak the bluestore cache sizes. I believe that by
> default, bluestore will not cache any data but instead will only
> attempt to cache its key/value store and metadata.
I suppose too because default ratio is to cache as much
Did anyone notice any performance loss on osd, mon, rgw nodes because of
the spectre/meltdown updates? What is general practice concerning these
updates?
Sort of follow up on this discussion.
https://www.mail-archive.com/ceph-users@lists.ceph.com/msg43136.html
https://access.redhat.com/arti
Hi Jakub,
for the crashing OSD could you please set
debug_bluestore=10
bluestore_bluefs_balance_failure_dump_interval=1
and collect more logs.
This will hopefully provide more insight on why additional space isn't
allocated for bluefs.
Thanks,
Igor
On 8/14/2018 12:41 PM, Jakub Stańczak
Hi Jaime,
Upgrading directly should not be a problem. It is usually recommended to go to
the latest minor release before upgrading major versions, but my own migration
from 10.2.10 to 12.2.5 went seamlessly and I can’t see of any technical
limitation which would hinder or prevent this proces
Hi Arvydas,
The error seems to suggest this is not an issue with your object data, but the
expected object digest data. I am unable to access where I stored my very hacky
diagnosis process for this, but our eventual fix was to locate the bucket or
files affected and then rename an object wit
I've seen the OS running on SATA DOMs and cheap USB sticks.
It works well for some time, and then it just falls apart.
Paul
2018-08-14 9:12 GMT+02:00 Burkhard Linke
:
> Hi,
>
>
> AFAIk SD cards (and SATA DOMs) do not have any kind of wear-leveling
> support. Even if the crappy write endurance of
I am keeping the wal and db for a ceph cluster on an SSD. I am using the
masif_bluestore_block_db_size / masif_bluestore_block_wal_size parameters
in ceph.conf to specify how big they should be. Should these values be the
same, or should one be much larger than the other?
R
On 08/15/2018 04:17 AM, Robert Stanford wrote:
> I am keeping the wal and db for a ceph cluster on an SSD. I am using
> the masif_bluestore_block_db_size / masif_bluestore_block_wal_size
> parameters in ceph.conf to specify how big they should be. Should these
> values be the same, or should on
28 matches
Mail list logo
