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 --
On Thu, Aug 16, 2018 at 9:00 PM, Robert Stanford
wrote:
>
> 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
I was using the ceph-volume create command, which I understand combines
the prepare and activate functions.
ceph-volume lvm create --osd-id 0 --bluestore --data /dev/sdc --block.db
/dev/sdb --block.wal /dev/sdb
That is the command context I've found on the web. Is it wrong?
Thanks
R
On Fri,
On Fri, Aug 17, 2018 at 10:24 AM, Robert Stanford
wrote:
>
> I was using the ceph-volume create command, which I understand combines the
> prepare and activate functions.
>
> ceph-volume lvm create --osd-id 0 --bluestore --data /dev/sdc --block.db
> /dev/sdb --block.wal /dev/sdb
>
> That is the
> ceph-volume lvm create --osd-id 0 --bluestore --data /dev/sdc --block.db
/dev/sdb --block.wal /dev/sdb
That command can't work... You're telling it to use the entire /dev/sdb
device for the db and then again to do it for the wal, but you can only use
the entire device once. There are 2 things w
What's more, I was planning on using this single journal device (SSD) for
4 OSDs. With filestore I simply told each OSD to use this drive, sdb, on
the command line, and it would create a new partition on that drive every
time I created an OSD. I thought it would be the same for BlueStore. So
th
On Fri, Aug 17, 2018 at 11:47 AM, Robert Stanford
wrote:
>
> What's more, I was planning on using this single journal device (SSD) for 4
> OSDs. With filestore I simply told each OSD to use this drive, sdb, on the
> command line, and it would create a new partition on that drive every time I
> c
This is helpful, thanks. Since the example is only for block.db, does
that imply that the wal should (can efficiently) live on the same disk as
data?
R
On Fri, Aug 17, 2018 at 10:50 AM Alfredo Deza wrote:
> On Fri, Aug 17, 2018 at 11:47 AM, Robert Stanford
> wrote:
> >
> > What's more, I w
The WAL will choose the fastest device available. If you do not specify
the WAL or DB, both will reside on the data disk. If you specify the DB,
then the WAL will reside with the DB. If you specify WAL without DB, the
DB will be on the data disk. This data and more is included at the top of
the
Does the block and/or wal partition need to be an LV? I just passed
ceph-volume the raw partition and it seems to be working fine.
On Fri, Aug 17, 2018 at 2:54 PM Alfredo Deza wrote:
> On Fri, Aug 17, 2018 at 10:24 AM, Robert Stanford
> wrote:
> >
> > I was using the ceph-volume create comman
On Fri, Aug 17, 2018 at 2:55 PM, David Turner wrote:
> Does the block and/or wal partition need to be an LV? I just passed
> ceph-volume the raw partition and it seems to be working fine.
A raw device is only allowed for data, but a partition is allowed for
wal/block.db
Not sure if by "raw part
Correct, I meant a partition of a block device. By 'raw partition I just
meant that there wasn't any LVM layer like in your example. Thanks Alfredo.
On Fri, Aug 17, 2018 at 3:05 PM Alfredo Deza wrote:
> On Fri, Aug 17, 2018 at 2:55 PM, David Turner
> wrote:
> > Does the block and/or wal parti
On 18 August 2018 at 03:06, David Turner wrote:
> The WAL will choose the fastest device available.
>
Any idea how it makes this determination automatically? is it doing a
hdparm -t or similar? is fastest=bandwidth, IOPs or latency?
___
ceph-users mail
I'm pretty certain it just assumes your only specifying a DB partition if
it's faster than the data and only specifying the WAL partition if it's
faster than the data and DB. It just trusts that your doing it right.
On Sun, Aug 19, 2018, 7:58 PM Nigel Williams
wrote:
>
> On 18 August 2018 at 03
14 matches
Mail list logo