Sorry,replay late.I mean the rbd snap. and the timestamp feature about luminous is:https://github.com/ceph/ceph/pull/12817On 08/16/2018 22:54，Gregory Farnum wrote：
On Mon, Aug 13, 2018 at 11:18 PM, hnuzhoulin2 wrote: hi,guys we have much snaps,and we want to clear. but can not
We are having issues with ensuring that object-map and fast-diff is working
correctly. Most of the time when there is an invalid fast-diff map, the flag is
set to correctly indicate this. We have a script that checks for this and
rebuilds object maps as required. If we don't fix these,
I am turning off resharding for Luminous with rgw dynamic resharding =
false on the rgw server. When I show the configuration on that server
(with ceph daemon), I see that it is false, like I expect. When I show the
configuration on the monitor servers, that setting shows up as "true". Do
I
Hello Ceph Users,
We are having issues with ensuring that object-map and fast-diff is working
correctly. Most of the time when there is an invalid fast-diff map, the flag is
set to correctly indicate this. We have a script that checks for this and
rebuilds object maps as required. If we don't
Hello!
Recently, we did data migration from one failure domain to another by changing the logical pool's crush_rule (ceph osd pool set crush_rule ). But after the migration, we found that some objects were destroyed and their copies on different OSDs were also destroyed.
After
Thanks for your help
Kind regards,
Glen Baars
From: Jason Dillaman
Sent: Thursday, 16 August 2018 10:21 PM
To: Glen Baars
Cc: ceph-users
Subject: Re: [ceph-users] RBD journal feature
On Thu, Aug 16, 2018 at 2:37 AM Glen Baars
mailto:g...@onsitecomputers.com.au>> wrote:
Is there any
I am following the steps to my filestore journal with a bluestore journal (
http://docs.ceph.com/docs/mimic/rados/operations/bluestore-migration/). It
is broken at ceph-volume lvm create. Here is my error:
--> Zapping successful for: /dev/sdc
Preparing sdc
Running command: /bin/ceph-authtool
Eugen you beat me!!!
On Thu, Aug 16, 2018 at 6:37 PM, Satish Patel wrote:
> I am new too but i had same question and this is my opinion (i would
> wait for other people to correct me or add more)
>
> A1. I didn't find any formula but i believe 10 to 20G is more than
> enough for each OSD ( there
I am new too but i had same question and this is my opinion (i would
wait for other people to correct me or add more)
A1. I didn't find any formula but i believe 10 to 20G is more than
enough for each OSD ( there are some variation like how long you going
to hold data etc..)
A2. basic rule is 5
The general consensus when this came out was that Ceph clusters shouldn't
be visible enough in your infrastructure to worry about vulnerabilities
from external sources. I went ahead and upgraded to patch some of my
clusters and didn't see any performance problems with them. Benchmarks
showed an
Hi,
1. Is there a formula to calculate the optimal size of partitions on
the SSD for each OSD, given their capacity and IO performance? Or is
there a rule of thumb on this?
Wido and probably some other users already mentioned 10 GB per 1 TB
OSD (1/100th of the OSD). Regarding the WAL size,
I am turning off resharding for Luminous with rgw dynamic resharding =
false on the rgw server. When I show the configuration on that server
(with ceph daemon), I see that it is false, like I expect. When I show the
configuration on the monitor servers, that setting shows up as "true". Do
I
Hi everyone,
As a newbie, I have some questions about using SSD as the Bluestore
journal device.
1. Is there a formula to calculate the optimal size of partitions on
the SSD for each OSD, given their capacity and IO performance? Or is
there a rule of thumb on this?
2. Is there a formula to find
Hmm!
I think i have to go hard way :) let me see if i can make it 9000
across the LAN. anyway thanks for suggestion.
On Thu, Aug 16, 2018 at 12:36 PM, Jack wrote:
> On the same network, all host shall have the same MTU
>
> Packets truncating can only happen on routers
>
> Let say you have an
On the same network, all host shall have the same MTU
Packets truncating can only happen on routers
Let say you have an OSD with mtu 9000, and a mon with mtu 1500
Communications from mon to osd will works, because the mon will send
1500 bytes-sized packets, and this is < 9000
However,
Reason i am asking because my Ceph-mon running on Openstack-ansible
LXC container, and there are many services running, Just for safe side
trying to avoid touching any of them.
If my ceph-mon works fine with MTU 1500 then it would be great. (
trying to understand what kind of communication OSD
>From experience i can tell you that all mons need to use the same MTU between
>eachother.
We moved from 1500 to 9000 a while ago and lost quorum while changing the MTU
of the mons. Once all mons where at 9000, everything was fine again.
Cluster ran fine with 9000 on the OSD's + Clients and
Folks,
I am changing all my OSD node MTU to 9000 and just wonder does
ceph-mon node need MTU 9000 ? I know that are not going to deal with
high volume data but just curious does that impact functionality if
ceph-mon running on MTU 1500 and all OSD data node run on MTU 9000
(FYI: they all are on
On 8/16/2018 5:40 PM, Hervé Ballans wrote:
Thanks Igor, indeed it does match !
# cat ceph-osd.0.log |grep wal
2018-08-16 11:55:27.182011 7fa47c106e00 4 rocksdb:
Options.max_total_wal_size: 0
Just an additional question, is it normal that on the osd log, I see
that
On Mon, Aug 13, 2018 at 11:18 PM, hnuzhoulin2 wrote:
> hi,guys
>
> we have much snaps,and we want to clear.
> but can not know the create time of these snaps.
>
> I know luminous have this feature default.but for jewel and hammer,have some
> hack way to get the create time?or it is just
On Thu, Aug 16, 2018 at 10:15 AM, Gregory Farnum wrote:
> Do note that while this works and is unlikely to break anything, it's
> not entirely ideal. The MDS was trying to probe the size and mtime of
> any files which were opened by clients that have since disappeared. By
> removing that list of
Reviewed the PR on github, but bringing it back to the list...
On Sat, Aug 11, 2018 at 2:39 PM, Sage Weil wrote:
> Two questions so far:
>
> 1) I marked the librados calls that take aui deprecated, but I can wire
> them up to still work. For example, if you call pool_create_with_auid it
> can
Thanks Igor, indeed it does match !
# cat ceph-osd.0.log |grep wal
*2018-08-16 11:55:27.181950 7fa47c106e00 4
rocksdb: Options.wal_dir: db*
2018-08-16 11:55:27.181983 7fa47c106e00 4 rocksdb:
Options.wal_bytes_per_sync: 0
2018-08-16
On Thu, Aug 16, 2018 at 2:37 AM Glen Baars
wrote:
> Is there any workaround that you can think of to correctly enable
> journaling on locked images?
>
You could add the "rbd journal pool = XYZ" configuration option to the
ceph.conf on the hosts currently using the images (or use 'rbd image-meta
On Thu, Aug 16, 2018 at 8:58 AM, Jonathan Woytek wrote:
> This did the trick! THANK YOU!
>
> After starting with the mds_wipe_sessions set and after removing the
> mds*_openfiles.0 entries in the metadata pool, mds started almost
> immediately and went to active. I verified that the filesystem
Hi Herve
actually absence of block.wal symlink is good enough symptom that DB and
WAL are merged .
But you can also inspect OSD startup log or check bluefs perf counters
after some load - corresponding WAL counters (total/used) should be zero.
Thanks,
Igor
On 8/16/2018 4:55 PM, Hervé
Hi all,
I'm setting up my Ceph cluster (last release of Luminous) and I'm
currently configuring OSD with WAL and DB on NVMe disk.
OSD data are on a SATA disk and Both WAL and DB are on the same
partition of the NVMe disk.
After creating partitions on the NVMe (block partitions, without
Hello,
I'm trying to mount a Ceph filesystem from a client within my Kubernetes
cluster. The client is dual-stacked (IPv4/IPv6) and the whole Ceph
platform is IPv6-only. The client can reach the monitor, osd and mds
servers via it's own default gateway. Ping and manual mount [1] in
terminal
Hi Thomas,
thanks for suggestion, but changing other objects or even object itself
doesn't helped out.
But I finally solved the problem:
1. Backed up problematic S3 object
2. Deleted it from S3
3. Stopped OSD
4. Flushed journal
5. Removed object directly from OSD
6. Started OSD
7. Repeated 3-6
This did the trick! THANK YOU!
After starting with the mds_wipe_sessions set and after removing the
mds*_openfiles.0 entries in the metadata pool, mds started almost
immediately and went to active. I verified that the filesystem could mount
again, shut down mds, removed the wipe sessions setting,
Hi,
Thanks for the quick reply.
The cluster is HEALTH_OK and we don't experience any issues, so I'll filter
these from our alert log, then :)
Cheers,
Balázs
2018-08-16 14:17 GMT+02:00 Gregory Farnum :
> This is normal operation; the challenge phase is new so it added a log
> message for it.
This is normal operation; the challenge phase is new so it added a log
message for it. We may turn that down in future but unless you are
experiencing issues in your cluster it should be good!
On Thu, Aug 16, 2018 at 7:04 AM Soltész, Balázs Péter <
soltesz.bal...@sztaki.mta.hu> wrote:
> Dear all,
On 16/08/2018 11:01, Willem Jan Withagen wrote:
Hi Norman,
Thanx for trying the Ceph port.
As you will find out it is still rough around the edges...
But please feel free to ask questions (on the ceph-user list)
Which I will try to help answer as good as I can.
And also feel free to send me
Dear all,
Our ceph cluster recently got upgraded to Luminous and now I'm seeing some
log messages I haven't seen before.
August 16th 2018, 12:33:54.763 -- osd.host.ip.1:6818/4106 >>
osd.host.ip.2:6818/39034 conn(0x55e9c33e4000 :6818
s=STATE_ACCEPTING_WAIT_CONNECT_MSG_AUTH pgs=531 cs=11
Hi,
Yes, we use GELF UDP:
[cid:B902F2D1-93EA-4332-A440-66D50A5CD578@croc.ru]
On 15 Aug 2018, at 14:28, Roman Steinhart
mailto:ro...@aternos.org>> wrote:
Hi,
thanks for your reply.
May I ask which type of input do you use in graylog?
"GELF UDP" or another one?
And which version of
Hi,
currently our ceph servers use 4.4.104, our clients mostly have newer
versions, something like 4.4.126.
I set mds_cache_memory_limit from 1G to 2G, and then to 4G. I still get the
warning
messages, and the messages would disappear in 1 or 2 minutes.
Did at least the number of clients
Hi Paul,
thanks for the detailed answer!
Am Dienstag, den 14.08.2018, 12:23 +0200 schrieb Paul Emmerich:
> IIRC this will create a rule that tries to selects n independent data
> centers
> Check the actual generated rule to validate this.
This is what it did and looking back it makes sense. ;)
Hi Norman,
Thanx for trying the Ceph port.
As you will find out it is still rough around the edges...
But please feel free to ask questions (on the ceph-user list)
Which I will try to help answer as good as I can.
And also feel free to send me feedback as much as you can to improve
either the
Hi, Eugen,
I set mds_cache_memory_limit from 1G to 2G, and then to 4G. I still get the
warning
messages, and the messages would disappear in 1 or 2 minutes.
Which version do your kernels use?
Zhenshi Zhou 于2018年8月13日周一 下午10:15写道：
> Hi Eugen,
> The command shows "mds_cache_memory_limit":
Is there any workaround that you can think of to correctly enable journaling on
locked images?
Kind regards,
Glen Baars
From: ceph-users On Behalf Of Glen Baars
Sent: Tuesday, 14 August 2018 9:36 PM
To: dilla...@redhat.com
Cc: ceph-users
Subject: Re: [ceph-users] RBD journal feature
Hello
40 matches
Mail list logo
