public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Drew DeVault <sir@cmpwn.com>
To: linux-kernel@vger.kernel.org
Subject: Failover root devices
Date: Wed, 16 Sep 2015 20:16:28 -0400	[thread overview]
Message-ID: <20150917001628.GA1126@homura> (raw)

I would like to see Linux support multiple root devices, so that it can
attempt one and move on to the next if it is not present. I've reviewed
the relevant code during boot-up and it seems like a good place for me
to submit my first patch, but I want to bring it up for discussion here
on LKML first.

The design I had in mind is something like this:

root=device;device;device;...

Where 'device' follows the current format (/dev/sdX, UUIDs, and so on,
via name_to_dev_t). I would modify prepare_namespace to iterate through
each offered root device until one works.

My use-case for this feature is that I would like to be able to change
the hardware of my machine and boot up differently based on what's
present. In my case, I would like to install my system normally, with
/boot on its own partition, and keep a seperate userspace on a flash
drive. Then, during boot-up, if the flash drive is present, it would be
used as the root device. If it's not present, a partition on disk would
be selected.

The only potential roadblock with this feature that comes to mind is
figuring out how to handle time-outs between root devices. I think it
would be wise to choose a sensible default value, and provide another
cmdline parameter to tweak it. The prepare_namespace flow might end up
looking something like this:

1. Wait rootdelay seconds
2. Check 1st device, not present
3. Recheck 1st device until rootfailoverdelay seconds has passed
4. Move on to 2nd device, present -> boot

Or:

1. Wait rootdelay seconds
2. Check 1st device, not present
3. Recheck 1st device until rootfailoverdelay seconds has passed
4. Move on to 2nd device, not present
5. Recheck 2st device until rootfailoverdelay seconds has passed
6. GOTO 2

And so on.

I also need to research how the various init systems interact with this
part of the boot process. I suspect systemd probably does something
silly wrt waiting for the root device. Since this feature would (of
course) be backwards compatible, it might be wise to just implement it
here and let the init systems add support for the feature themselves.

Advice? Who should I send my patches to when they're ready? Please CC
me, I do not subscribe to LKML.

--
Drew DeVault

             reply	other threads:[~2015-09-17  0:23 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-17  0:16 Drew DeVault [this message]
2015-09-17 16:02 ` Failover root devices Austin S Hemmelgarn
2015-09-17 17:30   ` Drew DeVault
2015-09-18 14:34     ` Austin S Hemmelgarn
2015-09-18 14:43       ` Drew DeVault
  -- strict thread matches above, loose matches on Subject: below --
2015-09-17 11:40 Ortwin Glück
2015-09-17 11:49 ` Drew DeVault
2015-09-17 17:47   ` Richard Weinberger
2015-09-17 17:49     ` Drew DeVault
2015-09-17 17:52       ` Richard Weinberger
2015-09-17 18:05         ` Drew DeVault
2015-09-17 18:17           ` Richard Weinberger
2015-09-17 18:18             ` Drew DeVault
2015-09-17 18:19               ` Richard Weinberger
2015-09-17 18:21                 ` Drew DeVault
2015-09-17 18:23                   ` Richard Weinberger
2015-09-17 18:28                     ` Drew DeVault
2015-09-18 14:59                       ` Ortwin Glück
2015-09-18 15:00                         ` Drew DeVault
2015-09-18 15:04                           ` Ortwin Glück
2015-09-18 15:36                             ` Austin S Hemmelgarn
2015-09-17 18:27             ` Harald Hoyer
2015-09-17 18:29               ` Drew DeVault
2015-09-17 18:33                 ` Richard Weinberger
2015-09-17 18:35                   ` Drew DeVault
2015-09-17 18:42                     ` Richard Weinberger
2015-09-17 18:29               ` Richard Weinberger
2015-09-17 18:37     ` Austin S Hemmelgarn
2015-09-17 18:40       ` Richard Weinberger
2015-09-18 14:40         ` Austin S Hemmelgarn

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=20150917001628.GA1126@homura \
    --to=sir@cmpwn.com \
    --cc=linux-kernel@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