linux-kernel - Re: Failover root devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <55FC22F6.6050308@cmpwn.com>
Date:	Fri, 18 Sep 2015 10:43:02 -0400
From:	Drew DeVault <sir@...wn.com>
To:	Austin S Hemmelgarn <ahferroin7@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Failover root devices

> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/