[ceph-users] killing ceph-disk [was Re: ceph-volume: migration and disk partition support]

Sage Weil sage at newdream.net
Mon Oct 16 15:34:55 PDT 2017

On Mon, 16 Oct 2017, Anthony Verevkin wrote:
> > From: "Sage Weil" <sage at newdream.net>
> > To: "Alfredo Deza" <adeza at redhat.com>
> > Cc: "ceph-devel" <ceph-devel at vger.kernel.org>, ceph-users at lists.ceph.com
> > Sent: Monday, October 9, 2017 11:09:29 AM
> > Subject: [ceph-users] killing ceph-disk [was Re: ceph-volume: migration and disk partition support]
> > 
> > To put this in context, the goal here is to kill ceph-disk in mimic.
> > 
> > Perhaps the "out" here is to support a "dir" option where the user
> > can
> > manually provision and mount an OSD on /var/lib/ceph/osd/*, with
> > 'journal'
> > or 'block' symlinks, and ceph-volume will do the last bits that
> > initialize
> > the filestore or bluestore OSD from there.  Then if someone has a
> > scenario
> > that isn't captured by LVM (or whatever else we support) they can
> > always
> > do it manually?
> > 
> In fact, now that bluestore only requires a few small files and symlinks 
> to remain in /var/lib/ceph/osd/* without the extra requirements for 
> xattrs support and xfs, why not simply leave those folders on OS root 
> filesystem and only point symlinks to bluestore block and db devices? 
> That would simplify the osd deployment so much - and the symlinks can 
> then point to /dev/disk/by-uuid or by-path or lvm path or whatever. The 
> only downside for this approach that I see is that disks themselves 
> would no longer be transferable between the hosts as those few files 
> that describe the OSD are no longer on the disk itself.

:) this is exactly what we're doing, actually:


We plan to backport this to luminous, hopefully in time for the next 
point release.

dm-crypt is still slightly annoying to set up, but it will still be much 


More information about the ceph-users mailing list