Re: Failover root devices
From: Drew DeVault
Date: Fri Sep 18 2015 - 10:43:10 EST
Possibly 'multirootdelay'?
I had the same thought, but wanted to avoid using any prefix other than
root*= since it would break tradition for this part of the kernel.
However, is there any case you can think of for wanting the values to be
different between rootdelay and the per-device scan delay other than
having the per-device scan delay be 0 and rootdelay be >0?
rootdelay is not really a part of this flow, to be honest. It's a number
of seconds that it just blocks before trying any devices at all. It
might not be necessary to make them seperate, though. What's the
"per-device scan delay" you're speaking of?
The way I'd probably write it would be:
1. Wait rootdelay seconds
2. Check for 1st device
3. If first device is not there, check for 2nd
4. If second device is not there, check next one
5. Repeat 4 until all devices are checked.
6. If a device wasn't found, check if we were told to loop until one is
found, and if so, start at 1 again.
And then add an option to tell it to wait 'rootdelay' seconds between
checking each device.
-snip-
> I think there's value in being able to tell it to go through each one
> exactly once, and halt like it does now if it can't find the filesystem
> on any of them. That should probably be the default behavior in fact,
> as it's more similar to what's done now.
What is the behavior if we weren't told to loop, but reach the end of
the list? I don't want to try one device for a while and move on - I'd
prefer to try all devices, then loop. With the other strategy, what
happens if you try the first device for a while, then move on to the
second, and the first device comes up while you're waiting on the
second? The way the user would want that to play out is to boot the
first device (since it is their preference, after all), but the actual
behavior will be to boot the second if it comes up during this time.
Secondarily, I've been thinking more about this, and I think it would be
wonderful to have such functionality in the nfsroot code as well (and
for that matter, also in any other built-in networked root filesystem
support).
I agree that it would be great, but there be dragons. I'm nervous to
attempt that in my first patch (or even my first few).
--
Drew DeVault
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/