linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Scott James Remnant <scott@canonical.com>
To: linux-hotplug@vger.kernel.org
Subject: Re: triggering udev rules based on the state of udevd
Date: Thu, 03 Jul 2008 16:29:52 +0000	[thread overview]
Message-ID: <1215102592.6739.25.camel@quest> (raw)
In-Reply-To: <20080702151527.GA22892@nostromo.devel.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On Wed, 2008-07-02 at 11:15 -0400, Bill Nottingham wrote:

> When using udev to automatically assemble MD devices (using mdadm --incremental),
> we've come across the following conundrum:
> 
> - If you just pass --incremental to mdadm, devices will only be started when all
>   members are present; you can never start a degraded device)
> 
> - If you pass --run (to solve this), devices will be started when the minimum
>   # of devices is present. This causes the array to always start in degraded
>   mode, causing unnecessary resyncs.
> 
> There doesn't seem to be a good happy medium that allows for degraded assembly
> when needed, but normal assembly in most cases.
> 
Surely only the user knows whether to start degraded or not?

Our approach is to incrementally assemble raid arrays through udev, and
after a timeout, if any raid we're expecting to be able to mount is not
ready, ask the user what they want to do about it.

	"RAID-1 device for /home is missing a volume.
	 Please ensure this volume is connected, or press ENTER to
	 use the device in a degraded mode."

Obvious advantage here is that we haven't given up, if the user realises
the cable is hanging out, they can plug it in and the message will go
away and the boot continues.

If they start in degraded mode, the RAID members remember that and the
next time you use --incremental, it'll start anyway. (fwict)

Scott
-- 
Scott James Remnant
scott@canonical.com

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

      parent reply	other threads:[~2008-07-03 16:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-02 15:15 triggering udev rules based on the state of udevd Bill Nottingham
2008-07-02 16:13 ` Kay Sievers
2008-07-02 16:26 ` Bill Nottingham
2008-07-02 16:32 ` Kay Sievers
2008-07-02 16:34 ` Bill Nottingham
2008-07-02 16:44 ` Bryan Kadzban
2008-07-02 16:45 ` Bill Nottingham
2008-07-02 22:12 ` Bryan Kadzban
2008-07-02 22:35 ` Hai Zaar
2008-07-03 13:09 ` Bill Nottingham
2008-07-03 16:29 ` Scott James Remnant [this message]

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=1215102592.6739.25.camel@quest \
    --to=scott@canonical.com \
    --cc=linux-hotplug@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).