[OpenAFS] Re: bonnie++ on OpenAFS

[Stephan Wiesand]

--Apple-Mail-142-834983302
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Matt,

On Nov 23, 2010, at 16:14 , Matt W. Benjamin wrote:

> Is "write-on-close" was an expectation which could be broken?  It is =
the case that AFS has strongly expressed that its semantics are (in =
general) _sync-on-close_, and it's meaning is that an application which =
has closed an AFS file may consider any writes it made to be stable, and =
visible to other clients.  Write stability is not assured only on close, =
an application may explicitly sync when convenient.  I'm not sure, =
first, how a client can ever have been assured that its writes were not =
stabilised before it closed its corresponding file(s), nor, how it would =
benefit from this?  For example, the client may not revoke its own =
operations on the file prior to closing it.  Which is to say, I think =
the CM is free to stabilise ordinary writes when any convenient =
opportunity arises.  Feel free to flame now...

as an AFS user, I never expected a guarantee that no data is actually =
written out to the fileserver ever before the file is closed on the =
client. After all, I'd like to be able to write files larger than the =
cache without having to close and reopen them in append mode.

But it's a huge advantage of AFS over other filesystems that this is the =
usual case for files of modest size compared to the cache, because it =
helps avoiding fragmentation on the fileserver. Imagine 1500 batch jobs =
on 200 clients dribbling into 3000 files in the same volume: I don't =
think that today's typical backend filesystems to the namei fileserver =
will be able to limit fragmentation as much as in the write-on-close =
case.

But as long as data is flushed in consecutive chunks as large as =
possible (or at least reasonably large if possible), it's perfectly ok =
to do it before the file is closed at least for our use case.

- Stephan
>=20
> Matt
>=20
>>=20
>> The problem is that we don't make good decisions when we decide to =20=

>> flush the cache. However, any change to flush items which are less =20=

>> active will be a behaviour change - in particular, on a multi-user =20=

>> system it would mean that one user could break write-on-close for =20
>> other users simply by filling the cache.
>>=20
>> Cheers,
>>=20
>> Simon.

--=20
Stephan Wiesand
DESY -DV-
Platanenenallee 6
15738 Zeuthen, Germany


--Apple-Mail-142-834983302
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
AwIaBQCgggGdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMTEy
MzE1NDgzMlowIwYJKoZIhvcNAQkEMRYEFCA/0iWZZAsOtL+M/6e+KY0waUyQMIGcBgkrBgEEAYI3
EAQxgY4wgYswgYIxCzAJBgNVBAYTAkRFMS4wLAYDVQQKEyVEZXV0c2NoZXMgRWxla3Ryb25lbi1T
eW5jaHJvdHJvbiBERVNZMQswCQYDVQQLEwJJVDEWMBQGA1UEAxMNREVTWSBDQSAtIEcwMjEeMBwG
CSqGSIb3DQEJARYPZGVzeS1jYUBkZXN5LmRlAgQOojLnMIGeBgsqhkiG9w0BCRACCzGBjqCBizCB
gjELMAkGA1UEBhMCREUxLjAsBgNVBAoTJURldXRzY2hlcyBFbGVrdHJvbmVuLVN5bmNocm90cm9u
IERFU1kxCzAJBgNVBAsTAklUMRYwFAYDVQQDEw1ERVNZIENBIC0gRzAyMR4wHAYJKoZIhvcNAQkB
Fg9kZXN5LWNhQGRlc3kuZGUCBA6iMucwDQYJKoZIhvcNAQEBBQAEggEAiN7lRVtWxUvFCyjGdQQv
aEwEVCN1u04S2wdTmNXph0F2/lZG870CduUYDrPCAHnCSWLHE89d+ET4vGOG4wyKr+BhgDt+7deq
wMzUHi5WkdcGPgz96tmkOb2Go9te0CF74+TPSXLDYwfJDyPPJOi1DwGBfcG/K7i29cBfiV4Palx0
2NsD4/OFvUnkWs0VcXRPsEdCBfLcOEkdFlKx/C3fNRlRkKTzqvyKUB9U8UY6+dlKz+mDItZr2khb
5Ra/JVjn0IwpePjGT9pW3qsw8GSM7kyml2DQBaK/98lo1DGUxBIEpPbAHJCR4p7B3J4JM7FFa5lX
mkPJZx3Pr3yalEWuNwAAAAAAAA==

--Apple-Mail-142-834983302--