The partition type code for a data partition is
4FBD7E29-9D25-41B8-AFD0-062C0CEFF05D
and the partition type code for a journal is
45B0969E-9B03-4F30-B4C6-5EC00CEFF106.
That will fix your udev rules and probably make systemctl recognize them.
What you need to do to remove the entries from your ceph.
We recently had a few inconsistent PGs crop up on one of our clusters, and
I wanted to describe the process used to repair them for review and perhaps
to help someone in the future.
Our state roughly matched David's described comment here:
http://tracker.ceph.com/issues/21388#note-1
However, we
The danger with mds.* and osd.* in commands is that the * is attempted to
be expanded by the command line before passing it to the command. That is
to say that if you have a file or folder called mds.anything, then you're
passing mds.anything to the command instead of mds.*. What you can do to
mi
Is there a way to hide the stripped objects from view? Sort of with the
rbd type pool
[@c01 mnt]# rados ls -p ec21 | head
test2G.img.0023
test2G.img.011c
test2G.img.0028
test2G.img.0163
test2G.img.01e7
test2G.img.008d
test
On 01/15/2018 09:57 AM, Victor Flávio wrote:
Hello,
We've have a radosgw cluster(verion 12.2.2) in multisite mode. Our
cluster is formed by one master realm, with one master zonegroup and
two zones(which one is the master zone).
We've followed the instructions of Ceph documentation to insta
Also worth pointing out something a bit obvious but: this kind of
faster/destructive migration should only be attempted if all your pools are at
least 3x replicated.
For example, if you had a 1x replicated pool you would lose data using this
approach.
-- Dan
> On Jan 11, 2018, at 14:24, Reed
On Wed, Jan 17, 2018 at 3:36 PM, Andras Pataki
wrote:
> Hi John,
>
> All our hosts are CentOS 7 hosts, the majority are 7.4 with kernel
> 3.10.0-693.5.2.el7.x86_64, with fuse 2.9.2-8.el7. We have some hosts that
> have slight variations in kernel versions, the oldest one are a handful of
> CentOS
We had to update the OS / kernel, chown all the data to ceph:ceph, and update
the partition type codes on both the OSDs and journals. After this udev and
systemd brought them up automatically.
From: ceph-users on behalf of Stefan Priebe
- Profihost AG
Sent: W
Hello,
i've some osds which were created under bobtail or argonaut (pre
ceph-deploy).
Those are not recognized as a ceph-osd@57.service . Also they have an
entry in the ceph.conf:
[osd.12]
host=1336
osd_data = /ceph/osd.$id/
osd_journal = /dev/disk/by-partlabel/journal$id
Zitat von Jens-U. Mozdzen
Hi Alfredo,
thank you for your comments:
Zitat von Alfredo Deza :
On Wed, Jan 10, 2018 at 8:57 AM, Jens-U. Mozdzen wrote:
Dear *,
has anybody been successful migrating Filestore OSDs to Bluestore OSDs,
keeping the OSD number? There have been a number of messages on
Hi John,
All our hosts are CentOS 7 hosts, the majority are 7.4 with kernel
3.10.0-693.5.2.el7.x86_64, with fuse 2.9.2-8.el7. We have some hosts
that have slight variations in kernel versions, the oldest one are a
handful of CentOS 7.3 hosts with kernel 3.10.0-514.21.1.el7.x86_64 and
fuse 2.
Hi,
I have been trying to asses performance on a 3 servers cluster for few days
now
The most I got you can see below ( 244 MBs for 3 OSDs and 15GB SSD
partition)
With 3 servers wouldn't make sense to get almost 3 times the speed of the
hard drive ?
Questions:
- what should be the performance I
On Wed, Jan 17, 2018 at 3:16 PM, Martin Emrich
wrote:
> Hi!
>
>
>
> I created a tracker ticket: http://tracker.ceph.com/issues/22721
>
> It also happens without a lifecycle rule (only versioning).
>
>
>
Thanks.
> I collected a log from the resharding process, after 10 minutes I canceled
> it. G
Hi!
I created a tracker ticket: http://tracker.ceph.com/issues/22721
It also happens without a lifecycle rule (only versioning).
I collected a log from the resharding process, after 10 minutes I canceled it.
Got 500MB log (gzipped still 20MB), so I cannot upload it to the bug tracker.
Regards,
Ah, I think I got it:
ceph@host1:~> ceph tell mds.* config set mds_cache_memory_limit 204800
[...]
mds.host2: Set mds_cache_memory_limit to 204800
[...]
mds.host1: Set mds_cache_memory_limit to 204800
:-)
Zitat von Florent B :
Of course, specifying mds.NAME is working (without *)
I don't know one yet, it would be helpful though. Maybe someone of the
more experienced users can enlighten us. :-)
Zitat von Florent B :
Of course, specifying mds.NAME is working (without *), but there's no
way to do it on all MDS at the same time ?
On 17/01/2018 12:54, Florent B wrote:
Oh, okay... can you run it on a specific host instead of "mds.*"?
I only get the error if I try to run the command on host 1 for host 2:
ceph@host1:~> ceph daemon mds.host2 config show
admin_socket: exception getting command descriptions: [Errno 2] No
such file or directory
ceph@host1:~> ceph
Can you try it on one of your MDS servers? It should work there.
Zitat von Florent B :
Hi,
Thank you but I got :
admin_socket: exception getting command descriptions: [Errno 2] No
such file or directory
On 17/01/2018 12:47, Eugen Block wrote:
Hi,
try it with
ceph daemon mds.* config
Hi,
try it with
ceph daemon mds.* config set mds_cache_size 0
Regards,
Eugen
Zitat von Florent B :
Hi,
I would like to reset "mds_cache_size" to its default value (0 in Luminous).
So I do :
ceph tell mds.* injectargs '--mds_cache_size 0'
I also tried :
ceph tell mds.* injectarg
On Tue, Jan 16, 2018 at 8:50 PM, Andras Pataki
wrote:
> Dear Cephers,
>
> We've upgraded the back end of our cluster from Jewel (10.2.10) to Luminous
> (12.2.2). The upgrade went smoothly for the most part, except we seem to be
> hitting an issue with cephfs. After about a day or two of use, the
On Wed, Jan 17, 2018 at 11:45 AM, Martin Emrich
wrote:
> Hi Orit!
>
>
>
> I did some tests, and indeed the combination of Versioning/Lifecycle with
> Resharding is the problem:
>
>
>
>- If I do not enable Versioning/Lifecycle, Autoresharding works fine.
>- If I disable Autoresharding but
Burkhard,
Thanks very much for info - I'll try the MDS with a 16GB
mds_cache_memory_limit (which leaves some buffer for extra memory
consumption on the machine), and report back if there are any issues
remaining.
Andras
On 01/17/2018 02:40 AM, Burkhard Linke wrote:
Hi,
On 01/16/2018 09:
Hello Alex,
We have a similar design. Two Datacenters at short distance (sharing
the same level 2 network) and one Datacenter at long range (more than
100km) for our Ceph cluster. Let's call these sites A1, A2 and B.
We set 2 Mons on A1, 2 Mons on A2 and 1 Mon on B. A1 and A2 shared a
same level
Hi Orit!
I did some tests, and indeed the combination of Versioning/Lifecycle with
Resharding is the problem:
* If I do not enable Versioning/Lifecycle, Autoresharding works fine.
* If I disable Autoresharding but enable Versioning+Lifecycle, pushing data
works fine, until I manually r
24 matches
Mail list logo