It would be nicer to keep such things on the mailinglist for future
reference external links expire etc.
-Original Message-
From: Vasu Kulkarni [mailto:vakul...@redhat.com]
Sent: vrijdag 1 juni 2018 18:51
To: ceph-users
Subject: Re: [ceph-users] Ceph EC profile, how are you using?
Is this documented somewhere? Because I would like to try this disk
encryption without lvm.
I thought about just creating a regular bluestore disk, and then use
dmcrypt on the 'ceph block' partition and use crypttab to automatically
mount it. And then have ceph use this device dmcrypt device
On 06/02/2018 11:09 AM, Marc Roos wrote:
> I would like to try this disk encryption without lvm.
> And then have ceph use this device dmcrypt device
You know that dmcrypt and LVM are tightly linked, right ?
The later is a tool to handle the former
___
>> I would like to try this disk encryption without lvm.
>
>> And then have ceph use this device dmcrypt device
>
>You know that dmcrypt and LVM are tightly linked, right ?
No I did not. What makes this tightly linked relevant?
___
ceph-users mailing
ceph-disk does not require bootstrap-osd/ceph.keyring and ceph-volume
does
[@~]# ceph-disk prepare --bluestore --zap-disk /dev/sdf
***
Found invalid GPT and valid MBR; converting MBR to GPT format.
*
[@ bootstrap-osd]# ceph-volume lvm prepare --bluestore --data /dev/sdf
Running command: /bin/ceph-authtool --gen-print-key
Running command: /bin/ceph --cluster ceph --name client.bootstrap-osd
--keyring /var/lib/ceph/bootstrap-osd/ceph.keyring -i - osd new
c32036fe-ca0b-47d1-be3f-e28943ee3a97
> Kill all mds first , create new fs with old pools , then run ‘fs reset’
> before start any MDS.
Brilliant! I can't wait to try it.
Thanks.
--
Bryan Henderson San Jose, California
___
ceph-users mailing list
ceph-use
I guess zap should be used instead of destroy? Maybe keep ceph-disk
backwards compatibility and keep destroy??
[root@c03 bootstrap-osd]# ceph-volume lvm zap /dev/sdf
--> Zapping: /dev/sdf
--> Unmounting /var/lib/ceph/osd/ceph-19
Running command: umount -v /var/lib/ceph/osd/ceph-19
stderr: umou
After removing manually the lv, vg, and pv, ceph-volume zap works, but
again the osd auth id still exists. (Although I have no idea how it
should know which to remove)
[@ bootstrap-osd]# ceph-volume lvm zap /dev/sdf
--> Zapping: /dev/sdf
Running command: /usr/sbin/cryptsetup status /dev/m
o+w? I don’t think that is necessary not?
drwxr-xr-x 2 ceph ceph 182 May 9 12:59 ceph-15
drwxr-xr-x 2 ceph ceph 182 May 9 20:51 ceph-14
drwxr-xr-x 2 ceph ceph 182 May 12 10:32 ceph-16
drwxr-xr-x 2 ceph ceph 6 Jun 2 17:21 ceph-19
drwxr-x--- 13 ceph ceph 168 Jun 2 17:47 .
drwxrwxrwt 2 ce
dmcrypt is part of the whole device-mapper infrastructure :
https://en.wikipedia.org/wiki/Device_mapper
LVM is nothing but a tool to manipulate device-mapper easily
I do not see any reason for using dmcrypt directly without LVM
On 06/02/2018 11:24 AM, Marc Roos wrote:
>
>>> I would like to try
The command mapping from ceph-disk to ceph-volume is certainly not 1:1.
What we are ended up using is:
ceph-volume lvm zap /dev/sda --destroy
This takes care of destroying Pvs and Lvs (as the documentation says).
Cheers,
Oliver
Am 02.06.2018 um 12:16 schrieb Marc Roos:
>
> I guess zap
Am 02.06.2018 um 11:44 schrieb Marc Roos:
>
>
> ceph-disk does not require bootstrap-osd/ceph.keyring and ceph-volume
> does
I believe that's expected when you use "prepare".
For ceph-volume, "prepare" already bootstraps the OSD and fetches a fresh OSD
id,
for which it needs the keyring.
For
>>
>>
>> ceph-disk does not require bootstrap-osd/ceph.keyring and ceph-volume
>> does
>
>I believe that's expected when you use "prepare".
>For ceph-volume, "prepare" already bootstraps the OSD and fetches a
fresh OSD id, for which it needs the keyring.
>For ceph-disk, this was not par
Am 02.06.2018 um 12:35 schrieb Marc Roos:
>
> o+w? I don’t think that is necessary not?
I also wondered about that, but it seems safe - it's only a tmpfs,
with sticky bit set - and all files within have:
-rw---.
as you can check.
Also, on our systems, we have:
drwxr-x---.
for /var/lib/ceph,
But leaves still entries in crush map and maybe also ceph auth ls, and
the dir in /var/lib/ceph/osd
-Original Message-
From: Oliver Freyermuth [mailto:freyerm...@physik.uni-bonn.de]
Sent: zaterdag 2 juni 2018 18:29
To: Marc Roos; ceph-users
Subject: Re: [ceph-users] Bug? ceph-volume
Ceph-disk didn't remove an osd from the cluster either. That has never been
a thing for ceph-disk or ceph-volume. There are other commands for that.
On Sat, Jun 2, 2018, 4:29 PM Marc Roos wrote:
>
> But leaves still entries in crush map and maybe also ceph auth ls, and
> the dir in /var/lib/ceph
If it creates it, should also remove it. Ceph-disk prepare did not
create it, so it is logical if it does not remove it. ceph-volume
however creates it, thus should remove it.
-Original Message-
From: David Turner [mailto:drakonst...@gmail.com]
Sent: zaterdag 2 juni 2018 23:36
To: M
One thing I'd love to see are benchmarks for ec profiles in different
host/network configurations. We're building a new cluster and I will
definitely be putting together an extensive benchmark panel together this
time around so that we know exactly what works best in what situations.
On Sat, Jun 2
19 matches
Mail list logo
