[OpenAFS] Re: [OpenAFS-devel] 1.6 and post-1.6 OpenAFS branch management and schedule
Stephan Wiesand
stephan.wiesand@desy.de
Thu, 17 Jun 2010 21:34:50 +0200
--Apple-Mail-279--4136135
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Hi Simon,
On Jun 17, 2010, at 21:01 , Simon Wilkinson wrote:
>=20
> On 17 Jun 2010, at 19:45, Christopher D. Clausen wrote:
>> Its fine to not have it enabled by default, but I can't see why one =
would remove the functionality from the source tree.
>=20
> Because every different configuration option you have doubles the =
complexity of testing the code. What actually tends to happen is that =
stuff that isn't enabled by default never actually gets tested when =
changes are made, and so ends up rotting.
hmm, that would apply to DAFS unless it's enabled by default starting =
with the 1.6 RCs?
> So, these options are dangerous both because we _know_ they can cause =
data loss now and that's only going to get worse in the future because =
nobody developing for the fileserver actually tests with them enabled.
Some not so small sites (including mine) seem to be using them - and =
actually don't test anything else right now.. We've been using these =
options ever since I started caring for AFS fileservers a couple of =
years ago. We've been bitten (just search the list for my cry for help =
and Jeff's answer pointing me to vol-bless), but I'm not sure by what. =
It possibly was fast-restart, but there's no proof. This case was a =
severe failure of the underlying (crappy) storage, and all data on such =
a device is at His mercy anyway... Digging through /vicepx back then =
revealed that all the data (and metadata) was actually completely =
intact, except for files being written at the time of the crash. The =
only actual problem was the blessed=3D0 in the volume header - and the =
salvager wasn't able to fix it.
> We have very limited developer effort available. Reducing the breadth =
of our code significantly improves our ability to add the new features =
that everyone says they want.
That's completely reasonable. But it clearly means that DAFS should the =
one and only option to run fileservers with 1.6+. Is this what's =
planned? Fine, let's test it (and nothing else) and get it ready. But if =
DAFS remains an option that has to be enabled explicitly at build time, =
I'm with Rainer and Christopher: please leave fast-restart and =
bitmap-later in place.
> My original proposal for both fast-restart and bitmap-later was that =
we should remove the configuration options but retain the code for one =
release cycle and then remove the code entirely in the next cycle. That =
hopefully prevents folk from running them thinking that they're in any =
way supported, but still allows those brave enough to do so some time to =
move over to demand attach.
Unless it's too hard to get them back without the configure options: ok.
Cheers,
Stephan
--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany
--Apple-Mail-279--4136135
Content-Disposition: attachment;
filename=smime.p7s
Content-Type: application/pkcs7-signature;
name=smime.p7s
Content-Transfer-Encoding: base64
MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFMDCCBSww
ggQUoAMCAQICBA6iMucwDQYJKoZIhvcNAQEFBQAwgYIxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVE
ZXV0c2NoZXMgRWxla3Ryb25lbi1TeW5jaHJvdHJvbiBERVNZMQswCQYDVQQLEwJJVDEWMBQGA1UE
AxMNREVTWSBDQSAtIEcwMjEeMBwGCSqGSIb3DQEJARYPZGVzeS1jYUBkZXN5LmRlMB4XDTA5MDgx
MjEyMjgwN1oXDTEyMDgxMTEyMjgwN1owZDELMAkGA1UEBhMCREUxLjAsBgNVBAoTJURldXRzY2hl
cyBFbGVrdHJvbmVuLVN5bmNocm90cm9uIERFU1kxCzAJBgNVBAsTAkRWMRgwFgYDVQQDEw9TdGVw
aGFuIFdpZXNhbmQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+a/R5pAi4opLKLl1e
z+krb0IhT+f8E/eXvwVKYYqx8Eze2vFfurFxtbpv3JmsgxwyQ7+lnYYC6OVz5MKutAB9PFsqGpzp
jddq5towBWzWUOc1tAeTdXLF34sUhqB5rrIqcWo2LdQes3EFOZ49H2L/+0FoD0fwZskts3y5IoAT
9ECr4IXM3NI5GTo+E+K96pCUxYGQfSya3W1Z2bYA3N80d6fWuDxRzWJD/XwIs5xuKR3x9GapeVE+
ov8KV7hu05pSD+m32PD0aKwXDBFVDAnyaE6jo3dT/YfSCd17FIwTfpms8kessqAvvkeLJw26deCB
EiIF+2eZc2LGqAzIexVvAgMBAAGjggHFMIIBwTAJBgNVHRMEAjAAMAsGA1UdDwQEAwIF4DApBgNV
HSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisGAQQBgjcUAgIwHQYDVR0OBBYEFAdgEEU6LcG4
SAuhYBrg4cWqE8/XMB8GA1UdIwQYMBaAFJSX58dzgIIijnL6/92eNIXjtHYUMCIGA1UdEQQbMBmB
F3N0ZXBoYW4ud2llc2FuZEBkZXN5LmRlMH0GA1UdHwR2MHQwOKA2oDSGMmh0dHA6Ly9jZHAxLnBj
YS5kZm4uZGUvZGVzeS1jYS9wdWIvY3JsL2dfY2FjcmwuY3JsMDigNqA0hjJodHRwOi8vY2RwMi5w
Y2EuZGZuLmRlL2Rlc3ktY2EvcHViL2NybC9nX2NhY3JsLmNybDCBmAYIKwYBBQUHAQEEgYswgYgw
QgYIKwYBBQUHMAKGNmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGVzeS1jYS9wdWIvY2FjZXJ0L2df
Y2FjZXJ0LmNydDBCBggrBgEFBQcwAoY2aHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZXN5LWNhL3B1
Yi9jYWNlcnQvZ19jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQBlp/2gTujsPJ6V5UT+H+4V
uUqYs46+Ep9uqn5E6rM2joXu3RhW7gtGfG8gYBYLr9og7aRMazEIYS4fo9tT4tb/pxZyHMY6QHvV
q3YQVUsV1THr3xBe5mACvPYXzQD7Lgo8rYlAwBUyV4ESwHnDkvc/hu3kSwefShd0qREl2Jql7S0N
dzHUaIRFi27Wm55rDXKiSZ2qQ5cxeqLkOXzMv5toE7qIO2axvv4AUMfQVHx/hSeK+A7QC3jef76o
M+WQpcVyKn1hDJPpR1oGku1JCglE5qNYcKnLlpkccAgJDL89LLvIgF9iti3tUomh0+LjZbNSxEb4
AALrRcjvix1eaVRUMYIDVDCCA1ACAQEwgYswgYIxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVEZXV0
c2NoZXMgRWxla3Ryb25lbi1TeW5jaHJvdHJvbiBERVNZMQswCQYDVQQLEwJJVDEWMBQGA1UEAxMN
REVTWSBDQSAtIEcwMjEeMBwGCSqGSIb3DQEJARYPZGVzeS1jYUBkZXN5LmRlAgQOojLnMAkGBSsO
AwIaBQCgggGdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDYx
NzE5MzQ1MVowIwYJKoZIhvcNAQkEMRYEFDVPSP0yfShJJUSr0p7hGoMBJ1dEMIGcBgkrBgEEAYI3
EAQxgY4wgYswgYIxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVEZXV0c2NoZXMgRWxla3Ryb25lbi1T
eW5jaHJvdHJvbiBERVNZMQswCQYDVQQLEwJJVDEWMBQGA1UEAxMNREVTWSBDQSAtIEcwMjEeMBwG
CSqGSIb3DQEJARYPZGVzeS1jYUBkZXN5LmRlAgQOojLnMIGeBgsqhkiG9w0BCRACCzGBjqCBizCB
gjELMAkGA1UEBhMCREUxLjAsBgNVBAoTJURldXRzY2hlcyBFbGVrdHJvbmVuLVN5bmNocm90cm9u
IERFU1kxCzAJBgNVBAsTAklUMRYwFAYDVQQDEw1ERVNZIENBIC0gRzAyMR4wHAYJKoZIhvcNAQkB
Fg9kZXN5LWNhQGRlc3kuZGUCBA6iMucwDQYJKoZIhvcNAQEBBQAEggEAb1jzhfad2KzpcoouCIBn
e9Bttf4/jDy3xJOoBLxDpOrkWSUHf48chV1OBoBbZPxk+T00mSYtDyI6qv+4YMrVaSF+IHnP9rs3
rFvPSSMYkONG7kUF6VdH22hak7CimhxDUuhtpRSNFVZgPdNOo5riTrrHI90uW3gUvymLaoWNiQZN
y8hfKmMz0POyu5HJ/CPNW5cgYsi2BnYiDEOYQyNSEIwC0gosrVcamknXLOTyybPNwoQv4Es42yqn
l/pP5wTuO6rYUBn0lx5IoBWC4pruCNuLYQr46PgphsuaPtPn7ytym7sdFgICO7BK0rcX2lgHRJV9
NPDa72uB1Kj8AwtTawAAAAAAAA==
--Apple-Mail-279--4136135--