Followup: weird behaviour with ceph osd pool create and the "crush-rule" parameter (suddenly changes behaviour)
4 Sep
2019
4 Sep
'19
3:42 p.m.
So, whilst debugging the behaviour in the first thread I created, I needed to create and
then destroy pools (to avoid running out of placement groups).
So, I did something like:
ceph osd pool create ec2pool 2048 2048 erasure glasgow-eci-test ec2pool 0
ceph osd pool create ec3pool 2048 2048 erasure glasgow-eci-test2 ec3pool 0
(for two different types of ecpool)
and then removed them with
ceph osd pool rm ec2pool ec2pool --yes-i-really-really-mean-it
ceph osd pool rm ec3pool ec3pool --yes-i-really-really-mean-it
Now, however, something seems to have broken, as if I attempt:
ceph osd pool create ec4pool 2048 2048 erasure glasgow-eci-test3 ec4pool 0
it fails with
Error ENOENT: specified rule ec4pool doesn't exist
(which, of course, it does not, as the whole point of the syntax is that ceph should build
the crush rule for me and name it appropriately; and this worked for all the previous
times).
ceph health returns HEALTH OK still.
Any suggestions? I've googled around a bit on this, but I can't seem to find
anyone discussing it...
Sam
4 Sep
4 Sep
5:25 p.m.
From memory if you specify a crush rule (even if it is the same as the pool name), it will
look for a rule and error if it is not found, rather than creating it.
The behaviour may have changed, but try explicitly not supplying a crush rule name (if you
haven't already).
Cheers,
Tom
-----Original Message-----
From: aoanla(a)gmail.com <aoanla(a)gmail.com>
Sent: 04 September 2019 14:43
To: ceph-users(a)ceph.io
Subject: [ceph-users] Followup: weird behaviour with ceph osd pool create and the
"crush-rule" parameter (suddenly changes behaviour)
So, whilst debugging the behaviour in the first thread I created, I needed to create and
then destroy pools (to avoid running out of placement groups).
So, I did something like:
ceph osd pool create ec2pool 2048 2048 erasure glasgow-eci-test ec2pool 0 ceph osd pool
create ec3pool 2048 2048 erasure glasgow-eci-test2 ec3pool 0
(for two different types of ecpool)
and then removed them with
ceph osd pool rm ec2pool ec2pool --yes-i-really-really-mean-it ceph osd pool rm ec3pool
ec3pool --yes-i-really-really-mean-it
Now, however, something seems to have broken, as if I attempt:
ceph osd pool create ec4pool 2048 2048 erasure glasgow-eci-test3 ec4pool 0
it fails with
Error ENOENT: specified rule ec4pool doesn't exist
(which, of course, it does not, as the whole point of the syntax is that ceph should build
the crush rule for me and name it appropriately; and this worked for all the previous
times).
ceph health returns HEALTH OK still.
Any suggestions? I've googled around a bit on this, but I can't seem to find
anyone discussing it...
Sam
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io To unsubscribe send an email to
ceph-users-leave(a)ceph.io
5:45 p.m.
Thanks for the suggestion, however...
As noted above: the previous invocations of ceph osd pool create have exactly the same
structure (and succeeded) as the one which fails.
I used the long form because trying to use the short form
(ceph osd pool create ec2pool 2048 2048 erasure glasgow-eci-test, for example)
produced other "fatal" errors [complaining about my not specifying the final
numeric positional parameter, even though it's optional].
Weirdly, though, you're right: going back to the short form suddenly works again...
so I'd like to revise my question to:
"why is the behaviour (and requirements) of ceph osd pool create inconsistent -
sometimes failing if you don't specify all the parameters, even optional ones, and
sometimes failing if you do, despite the 'rules' you're following being the
same?"
5 Sep
5 Sep
9:23 a.m.
Hi,
just a short note on automatic rule creation. A SUSE engineer pointed
me to the fact that this is actually documented [1] in the pool
creation section, under [crush-rule-name] it says:
For replicated pools it is the rule specified by the
osd pool
default crush rule config variable. This rule must exist. For
erasure pools it is erasure-code if the default erasure code profile
is used or {pool-name} otherwise. This rule will be created
implicitly if it doesn’t exist already.
I can't say anything about the inconsistency though, have you checked
the logs for hints?
Regards,
Eugen
[1] https://docs.ceph.com/docs/master/rados/operations/pools/#create-a-pool
Zitat von aoanla(a)gmail.com:
Thanks for the suggestion, however...
As noted above: the previous invocations of ceph osd pool create
have exactly the same structure (and succeeded) as the one which
fails.
I used the long form because trying to use the short form
(ceph osd pool create ec2pool 2048 2048 erasure glasgow-eci-test,
for example)
produced other "fatal" errors [complaining about my not specifying
the final numeric positional parameter, even though it's optional].
Weirdly, though, you're right: going back to the short form suddenly
works again...
so I'd like to revise my question to:
"why is the behaviour (and requirements) of ceph osd pool create
inconsistent - sometimes failing if you don't specify all the
parameters, even optional ones, and sometimes failing if you do,
despite the 'rules' you're following being the same?"
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
11:11 a.m.
As far as I could tell, there wasn't anything in the logs (at the default log levels),
other than the forwarded request to the mons...
(I did read the documentation, which is why I was using the long form... it's the
inconsistency which is problematic, especially since it also happens if you repeat an
earlier form of the command identically - sometimes it needs long form, sometimes short
form.)
6 Sep
6 Sep
1:07 a.m.
On Thu, Sep 5, 2019 at 2:12 AM <aoanla(a)gmail.com> wrote:
As far as I could tell, there wasn't anything in
the logs (at the default
log levels), other than the forwarded request to the mons...
(I did read the documentation, which is why I was using the long form...
it's the inconsistency which is problematic, especially since it also
happens if you repeat an earlier form of the command identically -
sometimes it needs long form, sometimes short form.)
Does it create a profile the first time it is run, then the second time
sees that a profile exists and wants you to specify it since it can't
create a profile of the same name?
2:11 p.m.
Nice thought but no:
in the case in the original post "ec4pool" had not been used as the name for a
pool, or a profile, before.
(and trying out combinations of deleting old profiles did not change the behavior).
1703
days inactive
1705
days old
6 comments
4 participants
participants (4)
-
aoanla＠gmail.com -
Eugen Block -
Robert LeBlanc -
Thomas Byrne - UKRI STFC