Project

General

Profile

Actions
Copy link

Feature #13942

closed

ceph-disk: support bluestore

Added by Sage Weil over 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
High
Assignee:
Loïc Dachary
Category:
-
Target version:
v10.0.4
% Done:

0%

Source:
other
Tags:
Backport:
Reviewed:
Affected Versions:
Pull request ID:

Description

bluestore (newstore) is based on a very small file system (with osd metadata, like the keyring, features, etc.) and one or more block devices. These devices are symlinked from the data directory, similar to how 'journal' is a symlink for the current FileStore.

ceph-disk create:

- create a small partition for osd_data
  - create a large partition (remainder of disk, by default) for data
    - symlink from $osd_data/block
  - [optional] create a mid-size partition for metadata (rocksdb).  use probably needs to specify this, since it'll probably be 1/Nth of their available SSD space on the host.
    - symlink from $osd_data/block.db
  - [optional] create a small partition for the write-ahead-log (basically the journal).  default size of 128MB is sufficient.
    - symlink from $osd_data/block.wal
  (note that block.db is preferable to block.wal as the space will be used for both the wal and sst files.  both would be used if the host has HDD, SSD, and NVME or NVRAM.)

- ceph-disk activate:

I think we can fully generalize this to re-use the journal UUID for any subsidiary block device (s/journal/block/ or similar). Then, make activate simply require that all symlinks in $osd_data resolve to devices before activating the OSD. The missing piece is that ceph-disk needs to figure out the uuid from a journal device in order to map it back to the parent osd_data device. Right now it does

out = _check_output(
            args=[
                'ceph-osd',
                '-i', '0',   # this is ignored
                '--get-journal-uuid',
                '--osd-journal',
                path,
                ],
            close_fds=True,
            )

but I think we need to replace this with some generic-ish way to identifying which OSD the device belongs too. For bluestore I can just stuff the uuid in the first block of the device? And then we can make a --get-device-uuid command that either parses the FileJournal header or a bluestore first-block-has-uuid header?

Related issues 1 (0 open — 1 closed)

Blocked by Ceph - Bug #14559: bluestore broken in current masterResolved01/29/2016

Actions
Actions
Copy link

Also available in: Atom PDF