From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751932AbbIROeZ (ORCPT ); Fri, 18 Sep 2015 10:34:25 -0400 Received: from mail-io0-f175.google.com ([209.85.223.175]:33603 "EHLO mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751009AbbIROeY (ORCPT ); Fri, 18 Sep 2015 10:34:24 -0400 Subject: Re: Failover root devices To: Drew DeVault , linux-kernel@vger.kernel.org References: <20150917001628.GA1126@homura> <55FAE401.8050700@gmail.com> <55FAF8C0.30205@cmpwn.com> From: Austin S Hemmelgarn Message-ID: <55FC20E5.1080801@gmail.com> Date: Fri, 18 Sep 2015 10:34:13 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <55FAF8C0.30205@cmpwn.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050806080004040003040100" X-Antivirus: avast! (VPS 150918-0, 2015-09-18), Outbound message X-Antivirus-Status: Clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a cryptographically signed message in MIME format. --------------ms050806080004040003040100 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable On 2015-09-17 13:30, Drew DeVault wrote: >> That said, using the term failover for this is probably not the best >> idea, many people associate it almost exclusively with online failover= >> and high-availability setups, and trying to do something like that wit= h >> the root file system is just asking for trouble (I'll be happy to go >> into specifics as to why if someone asks). > > Do you have a suggestion for another name for this feature? Maybe we ca= n > just call it "multiple root devices". The issue comes with the > associated command line options, like "rootfailoverdelay". Perhaps it > could be called "rootcycledelay". "rootdelay" is the obvious one, but > it's taken for another feature. Possibly 'multirootdelay'? 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=20 having the per-device scan delay be 0 and rootdelay be >0? 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=20 found, and if so, start at 1 again. And then add an option to tell it to wait 'rootdelay' seconds between=20 checking each device. > >>> 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. >> As for this, I'd say default to the first method, and then provide an >> option to switch to the second (both have practical uses). > > Sorry to cause confusion - these are actually the same method, but > handling different scenarios. The first is dealing with the first devic= e > being nonexistent, and the second device existing. The second is dealin= g > with both being nonexistent, and cycling between them until one of them= > shows up. After further thought, though, I think the best solution is a= > bit different: a new command line option called "rootmultiwait" or > similar, which is a maximum amount of time to wait for the user's first= > choice of root device to become available, then testing all devices > until that time runs out or the first choice becomes available. I think there's value in being able to tell it to go through each one=20 exactly once, and halt like it does now if it can't find the filesystem=20 on any of them. That should probably be the default behavior in fact,=20 as it's more similar to what's done now. 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=20 for that matter, also in any other built-in networked root filesystem=20 support). --------------ms050806080004040003040100 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC Brgwgga0MIIEnKADAgECAgMQblUwDQYJKoZIhvcNAQENBQAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNp Z25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcwHhcN MTUwMzI1MTkzNDM4WhcNMTUwOTIxMTkzNDM4WjBjMRgwFgYDVQQDEw9DQWNlcnQgV29UIFVz ZXIxIzAhBgkqhkiG9w0BCQEWFGFoZmVycm9pbjdAZ21haWwuY29tMSIwIAYJKoZIhvcNAQkB FhNhaGVtbWVsZ0BvaGlvZ3QuY29tMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA nQ/81tq0QBQi5w316VsVNfjg6kVVIMx760TuwA1MUaNQgQ3NyUl+UyFtjhpkNwwChjgAqfGd LIMTHAdObcwGfzO5uI2o1a8MHVQna8FRsU3QGouysIOGQlX8jFYXMKPEdnlt0GoQcd+BtESr pivbGWUEkPs1CwM6WOrs+09bAJP3qzKIr0VxervFrzrC5Dg9Rf18r9WXHElBuWHg4GYHNJ2V Ab8iKc10h44FnqxZK8RDN8ts/xX93i9bIBmHnFfyNRfiOUtNVeynJbf6kVtdHP+CRBkXCNRZ qyQT7gbTGD24P92PS2UTmDfplSBcWcTn65o3xWfesbf02jF6PL3BCrVnDRI4RgYxG3zFBJuG qvMoEODLhHKSXPAyQhwZINigZNdw5G1NqjXqUw+lIqdQvoPijK9J3eijiakh9u2bjWOMaleI SMRR6XsdM2O5qun1dqOrCgRkM0XSNtBQ2JjY7CycIx+qifJWsRaYWZz0aQU4ZrtAI7gVhO9h pyNaAGjvm7PdjEBiXq57e4QcgpwzvNlv8pG1c/hnt0msfDWNJtl3b6elhQ2Pz4w/QnWifZ8E BrFEmjeeJa2dqjE3giPVWrsH+lOvQQONsYJOuVb8b0zao4vrWeGmW2q2e3pdv0Axzm/60cJQ haZUv8+JdX9ZzqxOm5w5eUQSclt84u+D+hsCAwEAAaOCAVkwggFVMAwGA1UdEwEB/wQCMAAw VgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3VyIG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBo ZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNlcnQub3JnMA4GA1UdDwEB/wQEAwIDqDBABgNV HSUEOTA3BggrBgEFBQcDBAYIKwYBBQUHAwIGCisGAQQBgjcKAwQGCisGAQQBgjcKAwMGCWCG SAGG+EIEATAyBggrBgEFBQcBAQQmMCQwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmNhY2Vy dC5vcmcwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC5jYWNlcnQub3JnL3Jldm9rZS5j cmwwNAYDVR0RBC0wK4EUYWhmZXJyb2luN0BnbWFpbC5jb22BE2FoZW1tZWxnQG9oaW9ndC5j b20wDQYJKoZIhvcNAQENBQADggIBABr5e8W+NiTER+Q/7wiA2LxWN3UdhT3eZJjqqSlP370P KL5iWqeTfxQ67Ai/mHbJcT2PgAJ+/D2Ji+aRR03UWnU/vtOwzyDLUMstqnfl0Zs+sz/CJe7x nBA5jlpjC2DKuMVfbPze7eySaen7XSGFHKE1QoVIIpQ2kVjC4nbbJQnUbAVX1Iz29WxeVGt9 XYigz3tDPf3tglN+q23E7YjQl4abTIoM7i98yV1H9gfY8lFfKZ6jREB9+n6ie2EwS3Kat2mG tl2wBx4MfRnoSQSKsLKQ5oTwhWf0JqlFwpLfl374p0Njcykej9/jnWG8Ks1V/AXTHqI4eyIP Mf5yMZkPv7n7LS9WWKdG4Nd38iv4T2EiAaWsmgu+r81qL5CJu9AyA0SBS4ttKf6k3e63w2Mv N9R45vpQ3QhAhfWyFxFhZN95APe3YECDG3+XIRJpRYPEtHuIsOyzI70ajF93gg/BidvqKsmV MM2ccktDMfqwZXea6zey7F8Geu9R7BqjXmG2HlNuXu7e/xnHOgXf5D3wPmnRLlBhXL1Ch97a w2KjaupjpAHfFjv5kGnZXN87UvvlwzIZiKXwa3vTDwK+rrKn/sHPkfDZPSiyt/ZBIK6lX83P 34H/CzGg+Kx57rHYOIHGumIvpDa5vfWp8O0sGgawb1C2Aae4sTUVIWmIjVuGI062MYIE0TCC BM0CAQEwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNl cnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxBuVTANBglghkgBZQMEAgMFAKCCAiEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTUwOTE4MTQzNDEzWjBPBgkq hkiG9w0BCQQxQgRAaKklUw3wq1dFWn3zS5F2dnk86c4Rk0+rbVKL359SzENeNddQsIInJCU0 CMp7JkgyQcrGHrdd1DpnbMtdadGa9DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGRBgkrBgEEAYI3EAQxgYMwgYAweTEQMA4GA1UE ChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2Vy dC5vcmcCAxBuVTCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBDQTEe MBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAxBuVTAN BgkqhkiG9w0BAQEFAASCAgBTYhDlFAvuVWIIfrMHqt3T2o0C4LENVAiO9JMiYemefpDB/s17 bf8pjynOMWyS/Ft0FLcjVNTTe5E2MzyX3T5/KUBSjSfL9ik1ERR1jCo4v2l1ZQEshZHbv4I2 AMmLot7XSRp2h2QSWi+yT2Bg+tfdrcT44B4QZ06nUqiRqCZ2x4B7h1l107T5YILgMrigJNui bSTBeRKjTaCTSTbT7jMtESZbeoq62iCCuV+TGPFdVvuNCcGO9rZRHJOyQbyHsJ21Fz/SVzPb a0pab3ORnICXp8/2VtmCLuj1zh5zaVU+QO1NT5zBrCqjf2Z5n+6xB/WIO0QGUV1M7KuWg7Ue 5MiNykDTpI9NpygS2U6WbYFJJz6HYgR9RN0MOs5J2WVE36i6JqZQVgj9p8eMUthK039OjHqh RuhdIvBT7q51aVwiFx2/6G2JmIEV+xSFx90gCr4HTc4PDodiiAhHXoMdg82ygE9u6jsL0xEC X+jm0Ngkxn3UU6qMoyPIh4XF19kkM5pAP4gUSy7TCsa6pNKFzQ5rg3ItWAOydyORuUCd5bwr 0NvOrHMISrmhteSCWXd19VKa2TyINvwFPZvT7CngfdsN2bn1SV43/ouQDShyTJ3fqXeSi63S QYjvL+c+Ni4HjKcrbGYcUiH9tHfJ1hXfZteDMb6ttuVFjvY+EXSCQaKYVQAAAAAAAA== --------------ms050806080004040003040100--