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]
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ