From: Loic Dachary <loic@dachary.org>
To: Ken Dreyer <kdreyer@redhat.com>
Cc: Ceph Development <ceph-devel@vger.kernel.org>
Subject: Re: Backporting stability fixes for ceph-disk
Date: Thu, 4 Feb 2016 02:10:18 +0700 [thread overview]
Message-ID: <56B2509A.6090709@dachary.org> (raw)
In-Reply-To: <CALqRxCyTk5NPQJE7PTX4txbCPB2eagMBvH+V9HLHXkir4hij4g@mail.gmail.com>
On 04/02/2016 00:56, Ken Dreyer wrote:
> Hi Loic,
>
> Thanks for explaining the differences between Hammer's disk
> activations and Jewel's. I think I understand the problem better now.
>
> On Mon, Feb 1, 2016 at 10:53 PM, Loic Dachary <ldachary@redhat.com> wrote:
>> The conservative approach to the problem would be to cherry-pick what
>> we can (
>> https://github.com/dachary/ceph/commit/9dce05a8cdfc564c5162885bbb67a04ad7b95c5a
>> for instance ) and document known side effects of ceph-disk
>> instability so people know it's an annoyance but nothing destructive
>> or blocking. In the worst case scenario, deactivating the udev rules
>> and running ceph-disk prepare + ceph-disk activate manually or by
>> writing a script that does things sequentially is a viable workaround.
>
> This approach (documentation) sounds reasonable to me, and it makes
> sense that the larger re-architecture of running "ceph-disk activate"
> outside udev is only something that can happen in a major release
> boundary (in this case Infernalis / Jewel). Once we're happy that the
> docs for manually recovering are solid, we can possibly address it
> with a script as you suggest.
The script really is just adding a call to ceph-disk activate-all at boot time somewhere (/etc/rc.local maybe ?).
> If we can document the worst case scenario and what to do when
> ceph-disk-in-udev fails, that would really improve the user
> experience.
>
> What's the procedure for deactivating the Hammer udev rules, for example?
rm /lib/udev/rules.d/*ceph*
udevadm control --reload # maybe superfluous
>
> - Ken
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Loïc Dachary, Artisan Logiciel Libre
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2016-02-03 19:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 5:53 Backporting stability fixes for ceph-disk Loic Dachary
2016-02-03 17:56 ` Ken Dreyer
2016-02-03 19:10 ` Loic Dachary [this message]
2016-02-04 3:13 ` Ken Dreyer
2016-02-04 5:18 ` Loic Dachary
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56B2509A.6090709@dachary.org \
--to=loic@dachary.org \
--cc=ceph-devel@vger.kernel.org \
--cc=kdreyer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.