[PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Amit Gud]

VGhpcyBwYXRjaCBhZGRzIDQgbmV3IE5GUyBtb3VudCBvcHRpb25zKGFjZGlybWlubXMsIGFjZGly
bWF4bXMsIGFjcmVnbWlubXMsCmFjcmVnbWF4bXMpIGNvbnZlcnRpbmcgYWxyZWFkeSBleGlzdGlu
ZyBvbmUgaW50byBhIG1pbGxpc2Vjb25kIHJlc29sdXRpb24KaW5zdGVhZCBvZiBzZWNvbmRzLgoK
QWxzbywgbW9kaWZpZXMgdGhlIG1vdW50c3RhdHMgb3V0cHV0IHRvIG1pbGxpc2Vjb25kcyBpbnN0
ZWFkIG9mIHNlY29uZHMuCgpTaWduZWQtb2ZmLWJ5OiBBbWl0IEd1ZCA8YWd1ZEBha2FtYWkuY29t
PgoKQUcKLS0KTWF5IHRoZSBzb3VyY2Ugd2l0aCB5b3UuCmh0dHA6Ly93d3cuY2lzLmtzdS5lZHUv
fmd1ZAoKSW5kZXg6IGxpbnV4LTIuNi9mcy9uZnMvY2xpZW50LmMKPT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gbGlu
dXgtMi42Lm9yaWcvZnMvbmZzL2NsaWVudC5jCisrKyBsaW51eC0yLjYvZnMvbmZzL2NsaWVudC5j
CkBAIC03NzIsMTAgKzc3MiwxMCBAQCBzdGF0aWMgaW50IG5mc19pbml0X3NlcnZlcihzdHJ1Y3Qg
bmZzX3NlCiAJaWYgKGRhdGEtPndzaXplKQogCQlzZXJ2ZXItPndzaXplID0gbmZzX2Jsb2NrX3Np
emUoZGF0YS0+d3NpemUsIE5VTEwpOwogCi0Jc2VydmVyLT5hY3JlZ21pbiA9IGRhdGEtPmFjcmVn
bWluICogSFo7Ci0Jc2VydmVyLT5hY3JlZ21heCA9IGRhdGEtPmFjcmVnbWF4ICogSFo7Ci0Jc2Vy
dmVyLT5hY2Rpcm1pbiA9IGRhdGEtPmFjZGlybWluICogSFo7Ci0Jc2VydmVyLT5hY2Rpcm1heCA9
IGRhdGEtPmFjZGlybWF4ICogSFo7CisJc2VydmVyLT5hY3JlZ21pbiA9IChkYXRhLT5hY3JlZ21p
bm1zICogSFopIC8gMTAwMDsKKwlzZXJ2ZXItPmFjcmVnbWF4ID0gKGRhdGEtPmFjcmVnbWF4bXMg
KiBIWikgLyAxMDAwOworCXNlcnZlci0+YWNkaXJtaW4gPSAoZGF0YS0+YWNkaXJtaW5tcyAqIEha
KSAvIDEwMDA7CisJc2VydmVyLT5hY2Rpcm1heCA9IChkYXRhLT5hY2Rpcm1heG1zICogSFopIC8g
MTAwMDsKIAogCS8qIFN0YXJ0IGxvY2tkIGhlcmUsIGJlZm9yZSB3ZSBtaWdodCBlcnJvciBvdXQg
Ki8KIAllcnJvciA9IG5mc19zdGFydF9sb2NrZChzZXJ2ZXIpOwpAQCAtMTE3MywxMCArMTE3Mywx
MCBAQCBzdGF0aWMgaW50IG5mczRfaW5pdF9zZXJ2ZXIoc3RydWN0IG5mc19zCiAJaWYgKGRhdGEt
PndzaXplKQogCQlzZXJ2ZXItPndzaXplID0gbmZzX2Jsb2NrX3NpemUoZGF0YS0+d3NpemUsIE5V
TEwpOwogCi0Jc2VydmVyLT5hY3JlZ21pbiA9IGRhdGEtPmFjcmVnbWluICogSFo7Ci0Jc2VydmVy
LT5hY3JlZ21heCA9IGRhdGEtPmFjcmVnbWF4ICogSFo7Ci0Jc2VydmVyLT5hY2Rpcm1pbiA9IGRh
dGEtPmFjZGlybWluICogSFo7Ci0Jc2VydmVyLT5hY2Rpcm1heCA9IGRhdGEtPmFjZGlybWF4ICog
SFo7CisJc2VydmVyLT5hY3JlZ21pbiA9IChkYXRhLT5hY3JlZ21pbm1zICogSFopIC8gMTAwMDsK
KwlzZXJ2ZXItPmFjcmVnbWF4ID0gKGRhdGEtPmFjcmVnbWF4bXMgKiBIWikgLyAxMDAwOworCXNl
cnZlci0+YWNkaXJtaW4gPSAoZGF0YS0+YWNkaXJtaW5tcyAqIEhaKSAvIDEwMDA7CisJc2VydmVy
LT5hY2Rpcm1heCA9IChkYXRhLT5hY2Rpcm1heG1zICogSFopIC8gMTAwMDsKIAogCXNlcnZlci0+
cG9ydCA9IGRhdGEtPm5mc19zZXJ2ZXIucG9ydDsKIApJbmRleDogbGludXgtMi42L2ZzL25mcy9p
bnRlcm5hbC5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpbnV4LTIuNi5vcmlnL2ZzL25mcy9pbnRlcm5hbC5o
CisrKyBsaW51eC0yLjYvZnMvbmZzL2ludGVybmFsLmgKQEAgLTM2LDggKzM2LDggQEAgc3RydWN0
IG5mc19wYXJzZWRfbW91bnRfZGF0YSB7CiAJaW50CQkJZmxhZ3M7CiAJaW50CQkJcnNpemUsIHdz
aXplOwogCWludAkJCXRpbWVvLCByZXRyYW5zOwotCWludAkJCWFjcmVnbWluLCBhY3JlZ21heCwK
LQkJCQlhY2Rpcm1pbiwgYWNkaXJtYXg7CisJaW50CQkJYWNyZWdtaW5tcywgYWNyZWdtYXhtcywK
KwkJCQlhY2Rpcm1pbm1zLCBhY2Rpcm1heG1zOwogCWludAkJCW5hbWxlbjsKIAl1bnNpZ25lZCBp
bnQJCW9wdGlvbnM7CiAJdW5zaWduZWQgaW50CQlic2l6ZTsKSW5kZXg6IGxpbnV4LTIuNi9mcy9u
ZnMvbmZzcm9vdC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpbnV4LTIuNi5vcmlnL2ZzL25mcy9uZnNyb290
LmMKKysrIGxpbnV4LTIuNi9mcy9uZnMvbmZzcm9vdC5jCkBAIC0yOTcsMTAgKzI5NywxMCBAQCBz
dGF0aWMgaW50IF9faW5pdCByb290X25mc19uYW1lKGNoYXIgKm5hCiAJbmZzX2RhdGEuZmxhZ3Mg
ICAgPSBORlNfTU9VTlRfTk9OTE07CS8qIE5vIGxvY2tkIGluIG5mcyByb290IHlldCAqLwogCW5m
c19kYXRhLnJzaXplICAgID0gTkZTX0RFRl9GSUxFX0lPX1NJWkU7CiAJbmZzX2RhdGEud3NpemUg
ICAgPSBORlNfREVGX0ZJTEVfSU9fU0laRTsKLQluZnNfZGF0YS5hY3JlZ21pbiA9IE5GU19ERUZf
QUNSRUdNSU47Ci0JbmZzX2RhdGEuYWNyZWdtYXggPSBORlNfREVGX0FDUkVHTUFYOwotCW5mc19k
YXRhLmFjZGlybWluID0gTkZTX0RFRl9BQ0RJUk1JTjsKLQluZnNfZGF0YS5hY2Rpcm1heCA9IE5G
U19ERUZfQUNESVJNQVg7CisJbmZzX2RhdGEuYWNyZWdtaW4gPSBORlNfREVGX0FDUkVHTUlOX01T
IC8gMTAwMDsKKwluZnNfZGF0YS5hY3JlZ21heCA9IE5GU19ERUZfQUNSRUdNQVhfTVMgLyAxMDAw
OworCW5mc19kYXRhLmFjZGlybWluID0gTkZTX0RFRl9BQ0RJUk1JTl9NUyAvIDEwMDA7CisJbmZz
X2RhdGEuYWNkaXJtYXggPSBORlNfREVGX0FDRElSTUFYX01TIC8gMTAwMDsKIAlzdHJjcHkoYnVm
LCBORlNfUk9PVCk7CiAKIAkvKiBQcm9jZXNzIG9wdGlvbnMgcmVjZWl2ZWQgZnJvbSB0aGUgcmVt
b3RlIHNlcnZlciAqLwpJbmRleDogbGludXgtMi42L2ZzL25mcy9zdXBlci5jCj09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K
LS0tIGxpbnV4LTIuNi5vcmlnL2ZzL25mcy9zdXBlci5jCisrKyBsaW51eC0yLjYvZnMvbmZzL3N1
cGVyLmMKQEAgLTg1LDYgKzg1LDggQEAgZW51bSB7CiAJT3B0X3RpbWVvLCBPcHRfcmV0cmFucywK
IAlPcHRfYWNyZWdtaW4sIE9wdF9hY3JlZ21heCwKIAlPcHRfYWNkaXJtaW4sIE9wdF9hY2Rpcm1h
eCwKKwlPcHRfYWNyZWdtaW5tcywgT3B0X2FjcmVnbWF4bXMsCisJT3B0X2FjZGlybWlubXMsIE9w
dF9hY2Rpcm1heG1zLAogCU9wdF9hY3RpbWVvLAogCU9wdF9uYW1lbGVuLAogCU9wdF9tb3VudHBv
cnQsCkBAIC0xNDksNiArMTUxLDEwIEBAIHN0YXRpYyBjb25zdCBtYXRjaF90YWJsZV90IG5mc19t
b3VudF9vcHQKIAl7IE9wdF9hY3JlZ21heCwgImFjcmVnbWF4PSV1IiB9LAogCXsgT3B0X2FjZGly
bWluLCAiYWNkaXJtaW49JXUiIH0sCiAJeyBPcHRfYWNkaXJtYXgsICJhY2Rpcm1heD0ldSIgfSwK
Kwl7IE9wdF9hY3JlZ21pbm1zLCAiYWNyZWdtaW5tcz0ldSIgfSwKKwl7IE9wdF9hY3JlZ21heG1z
LCAiYWNyZWdtYXhtcz0ldSIgfSwKKwl7IE9wdF9hY2Rpcm1pbm1zLCAiYWNkaXJtaW5tcz0ldSIg
fSwKKwl7IE9wdF9hY2Rpcm1heG1zLCAiYWNkaXJtYXhtcz0ldSIgfSwKIAl7IE9wdF9hY3RpbWVv
LCAiYWN0aW1lbz0ldSIgfSwKIAl7IE9wdF9uYW1lbGVuLCAibmFtbGVuPSV1IiB9LAogCXsgT3B0
X21vdW50cG9ydCwgIm1vdW50cG9ydD0ldSIgfSwKQEAgLTUzNSwxNCArNTQxLDE0IEBAIHN0YXRp
YyB2b2lkIG5mc19zaG93X21vdW50X29wdGlvbnMoc3RydWMKIAlpZiAobmZzcy0+YnNpemUgIT0g
MCkKIAkJc2VxX3ByaW50ZihtLCAiLGJzaXplPSV1IiwgbmZzcy0+YnNpemUpOwogCXNlcV9wcmlu
dGYobSwgIixuYW1sZW49JXUiLCBuZnNzLT5uYW1lbGVuKTsKLQlpZiAobmZzcy0+YWNyZWdtaW4g
IT0gTkZTX0RFRl9BQ1JFR01JTipIWiB8fCBzaG93ZGVmYXVsdHMpCi0JCXNlcV9wcmludGYobSwg
IixhY3JlZ21pbj0ldSIsIG5mc3MtPmFjcmVnbWluL0haKTsKLQlpZiAobmZzcy0+YWNyZWdtYXgg
IT0gTkZTX0RFRl9BQ1JFR01BWCpIWiB8fCBzaG93ZGVmYXVsdHMpCi0JCXNlcV9wcmludGYobSwg
IixhY3JlZ21heD0ldSIsIG5mc3MtPmFjcmVnbWF4L0haKTsKLQlpZiAobmZzcy0+YWNkaXJtaW4g
IT0gTkZTX0RFRl9BQ0RJUk1JTipIWiB8fCBzaG93ZGVmYXVsdHMpCi0JCXNlcV9wcmludGYobSwg
IixhY2Rpcm1pbj0ldSIsIG5mc3MtPmFjZGlybWluL0haKTsKLQlpZiAobmZzcy0+YWNkaXJtYXgg
IT0gTkZTX0RFRl9BQ0RJUk1BWCpIWiB8fCBzaG93ZGVmYXVsdHMpCi0JCXNlcV9wcmludGYobSwg
IixhY2Rpcm1heD0ldSIsIG5mc3MtPmFjZGlybWF4L0haKTsKKwlpZiAobmZzcy0+YWNyZWdtaW4g
IT0gKE5GU19ERUZfQUNSRUdNSU5fTVMqSFopLzEwMDAgfHwgc2hvd2RlZmF1bHRzKQorCQlzZXFf
cHJpbnRmKG0sICIsYWNyZWdtaW5tcz0ldSIsIChuZnNzLT5hY3JlZ21pbioxMDAwKS9IWik7CisJ
aWYgKG5mc3MtPmFjcmVnbWF4ICE9IChORlNfREVGX0FDUkVHTUFYX01TKkhaKS8xMDAwIHx8IHNo
b3dkZWZhdWx0cykKKwkJc2VxX3ByaW50ZihtLCAiLGFjcmVnbWF4bXM9JXUiLCAobmZzcy0+YWNy
ZWdtYXgqMTAwMCkvSFopOworCWlmIChuZnNzLT5hY2Rpcm1pbiAhPSAoTkZTX0RFRl9BQ0RJUk1J
Tl9NUypIWikvMTAwMCB8fCBzaG93ZGVmYXVsdHMpCisJCXNlcV9wcmludGYobSwgIixhY2Rpcm1p
bm1zPSV1IiwgKG5mc3MtPmFjZGlybWluKjEwMDApL0haKTsKKwlpZiAobmZzcy0+YWNkaXJtYXgg
IT0gKE5GU19ERUZfQUNESVJNQVhfTVMqSFopLzEwMDAgfHwgc2hvd2RlZmF1bHRzKQorCQlzZXFf
cHJpbnRmKG0sICIsYWNkaXJtYXhtcz0ldSIsIChuZnNzLT5hY2Rpcm1heCoxMDAwKS9IWik7CiAJ
Zm9yIChuZnNfaW5mb3AgPSBuZnNfaW5mbzsgbmZzX2luZm9wLT5mbGFnOyBuZnNfaW5mb3ArKykg
ewogCQlpZiAobmZzcy0+ZmxhZ3MgJiBuZnNfaW5mb3AtPmZsYWcpCiAJCQlzZXFfcHV0cyhtLCBu
ZnNfaW5mb3AtPnN0cik7CkBAIC0xMTM4LDM2ICsxMTQ0LDY0IEBAIHN0YXRpYyBpbnQgbmZzX3Bh
cnNlX21vdW50X29wdGlvbnMoY2hhcgogCQkJCWVycm9ycysrOwogCQkJCW5mc19wYXJzZV9pbnZh
bGlkX3ZhbHVlKCJhY3JlZ21pbiIpOwogCQkJfSBlbHNlCi0JCQkJbW50LT5hY3JlZ21pbiA9IG9w
dGlvbjsKKwkJCQltbnQtPmFjcmVnbWlubXMgPSBvcHRpb24gKiAxMDAwOwogCQkJYnJlYWs7CiAJ
CWNhc2UgT3B0X2FjcmVnbWF4OgogCQkJaWYgKG1hdGNoX2ludChhcmdzLCAmb3B0aW9uKSB8fCBv
cHRpb24gPCAwKSB7CiAJCQkJZXJyb3JzKys7CiAJCQkJbmZzX3BhcnNlX2ludmFsaWRfdmFsdWUo
ImFjcmVnbWF4Iik7CiAJCQl9IGVsc2UKLQkJCQltbnQtPmFjcmVnbWF4ID0gb3B0aW9uOworCQkJ
CW1udC0+YWNyZWdtYXhtcyA9IG9wdGlvbiAqIDEwMDA7CiAJCQlicmVhazsKIAkJY2FzZSBPcHRf
YWNkaXJtaW46CiAJCQlpZiAobWF0Y2hfaW50KGFyZ3MsICZvcHRpb24pIHx8IG9wdGlvbiA8IDAp
IHsKIAkJCQllcnJvcnMrKzsKIAkJCQluZnNfcGFyc2VfaW52YWxpZF92YWx1ZSgiYWNkaXJtaW4i
KTsKIAkJCX0gZWxzZQotCQkJCW1udC0+YWNkaXJtaW4gPSBvcHRpb247CisJCQkJbW50LT5hY2Rp
cm1pbm1zID0gb3B0aW9uICogMTAwMDsKIAkJCWJyZWFrOwogCQljYXNlIE9wdF9hY2Rpcm1heDoK
IAkJCWlmIChtYXRjaF9pbnQoYXJncywgJm9wdGlvbikgfHwgb3B0aW9uIDwgMCkgewogCQkJCWVy
cm9ycysrOwogCQkJCW5mc19wYXJzZV9pbnZhbGlkX3ZhbHVlKCJhY2Rpcm1heCIpOwogCQkJfSBl
bHNlCi0JCQkJbW50LT5hY2Rpcm1heCA9IG9wdGlvbjsKKwkJCQltbnQtPmFjZGlybWF4bXMgPSBv
cHRpb24gKiAxMDAwOworCQkJYnJlYWs7CisJCWNhc2UgT3B0X2FjcmVnbWlubXM6CisJCQlpZiAo
bWF0Y2hfaW50KGFyZ3MsICZvcHRpb24pIHx8IG9wdGlvbiA8IDApIHsKKwkJCQllcnJvcnMrKzsK
KwkJCQluZnNfcGFyc2VfaW52YWxpZF92YWx1ZSgiYWNyZWdtaW4iKTsKKwkJCX0gZWxzZQorCQkJ
CW1udC0+YWNyZWdtaW5tcyA9IG9wdGlvbjsKKwkJCWJyZWFrOworCQljYXNlIE9wdF9hY3JlZ21h
eG1zOgorCQkJaWYgKG1hdGNoX2ludChhcmdzLCAmb3B0aW9uKSB8fCBvcHRpb24gPCAwKSB7CisJ
CQkJZXJyb3JzKys7CisJCQkJbmZzX3BhcnNlX2ludmFsaWRfdmFsdWUoImFjcmVnbWF4Iik7CisJ
CQl9IGVsc2UKKwkJCQltbnQtPmFjcmVnbWF4bXMgPSBvcHRpb247CisJCQlicmVhazsKKwkJY2Fz
ZSBPcHRfYWNkaXJtaW5tczoKKwkJCWlmIChtYXRjaF9pbnQoYXJncywgJm9wdGlvbikgfHwgb3B0
aW9uIDwgMCkgeworCQkJCWVycm9ycysrOworCQkJCW5mc19wYXJzZV9pbnZhbGlkX3ZhbHVlKCJh
Y2Rpcm1pbiIpOworCQkJfSBlbHNlCisJCQkJbW50LT5hY2Rpcm1pbm1zID0gb3B0aW9uOworCQkJ
YnJlYWs7CisJCWNhc2UgT3B0X2FjZGlybWF4bXM6CisJCQlpZiAobWF0Y2hfaW50KGFyZ3MsICZv
cHRpb24pIHx8IG9wdGlvbiA8IDApIHsKKwkJCQllcnJvcnMrKzsKKwkJCQluZnNfcGFyc2VfaW52
YWxpZF92YWx1ZSgiYWNkaXJtYXgiKTsKKwkJCX0gZWxzZQorCQkJCW1udC0+YWNkaXJtYXhtcyA9
IG9wdGlvbjsKIAkJCWJyZWFrOwogCQljYXNlIE9wdF9hY3RpbWVvOgogCQkJaWYgKG1hdGNoX2lu
dChhcmdzLCAmb3B0aW9uKSB8fCBvcHRpb24gPCAwKSB7CiAJCQkJZXJyb3JzKys7CiAJCQkJbmZz
X3BhcnNlX2ludmFsaWRfdmFsdWUoImFjdGltZW8iKTsKIAkJCX0gZWxzZQotCQkJCW1udC0+YWNy
ZWdtaW4gPSBtbnQtPmFjcmVnbWF4ID0KLQkJCQltbnQtPmFjZGlybWluID0gbW50LT5hY2Rpcm1h
eCA9IG9wdGlvbjsKKwkJCQltbnQtPmFjcmVnbWlubXMgPSBtbnQtPmFjcmVnbWF4bXMgPQorCQkJ
CW1udC0+YWNkaXJtaW5tcyA9IG1udC0+YWNkaXJtYXhtcyA9IG9wdGlvbiAqIDEwMDA7CiAJCQli
cmVhazsKIAkJY2FzZSBPcHRfbmFtZWxlbjoKIAkJCWlmIChtYXRjaF9pbnQoYXJncywgJm9wdGlv
bikgfHwgb3B0aW9uIDwgMCkgewpAQCAtMTU5NiwxMCArMTYzMCwxMCBAQCBzdGF0aWMgaW50IG5m
c192YWxpZGF0ZV9tb3VudF9kYXRhKHZvaWQKIAlhcmdzLT5mbGFncwkJPSAoTkZTX01PVU5UX1ZF
UjMgfCBORlNfTU9VTlRfVENQKTsKIAlhcmdzLT5yc2l6ZQkJPSBORlNfTUFYX0ZJTEVfSU9fU0la
RTsKIAlhcmdzLT53c2l6ZQkJPSBORlNfTUFYX0ZJTEVfSU9fU0laRTsKLQlhcmdzLT5hY3JlZ21p
bgkJPSBORlNfREVGX0FDUkVHTUlOOwotCWFyZ3MtPmFjcmVnbWF4CQk9IE5GU19ERUZfQUNSRUdN
QVg7Ci0JYXJncy0+YWNkaXJtaW4JCT0gTkZTX0RFRl9BQ0RJUk1JTjsKLQlhcmdzLT5hY2Rpcm1h
eAkJPSBORlNfREVGX0FDRElSTUFYOworCWFyZ3MtPmFjcmVnbWlubXMJPSBORlNfREVGX0FDUkVH
TUlOX01TOworCWFyZ3MtPmFjcmVnbWF4bXMJPSBORlNfREVGX0FDUkVHTUFYX01TOworCWFyZ3Mt
PmFjZGlybWlubXMJPSBORlNfREVGX0FDRElSTUlOX01TOworCWFyZ3MtPmFjZGlybWF4bXMJPSBO
RlNfREVGX0FDRElSTUFYX01TOwogCWFyZ3MtPm1vdW50X3NlcnZlci5wb3J0CT0gMDsJLyogYXV0
b2JpbmQgdW5sZXNzIHVzZXIgc2V0cyBwb3J0ICovCiAJYXJncy0+bmZzX3NlcnZlci5wb3J0CT0g
MDsJLyogYXV0b2JpbmQgdW5sZXNzIHVzZXIgc2V0cyBwb3J0ICovCiAJYXJncy0+bmZzX3NlcnZl
ci5wcm90b2NvbCA9IFhQUlRfVFJBTlNQT1JUX1RDUDsKQEAgLTE2NDMsMTAgKzE2NzcsMTAgQEAg
c3RhdGljIGludCBuZnNfdmFsaWRhdGVfbW91bnRfZGF0YSh2b2lkCiAJCWFyZ3MtPndzaXplCQk9
IGRhdGEtPndzaXplOwogCQlhcmdzLT50aW1lbwkJPSBkYXRhLT50aW1lbzsKIAkJYXJncy0+cmV0
cmFucwkJPSBkYXRhLT5yZXRyYW5zOwotCQlhcmdzLT5hY3JlZ21pbgkJPSBkYXRhLT5hY3JlZ21p
bjsKLQkJYXJncy0+YWNyZWdtYXgJCT0gZGF0YS0+YWNyZWdtYXg7Ci0JCWFyZ3MtPmFjZGlybWlu
CQk9IGRhdGEtPmFjZGlybWluOwotCQlhcmdzLT5hY2Rpcm1heAkJPSBkYXRhLT5hY2Rpcm1heDsK
KwkJYXJncy0+YWNyZWdtaW5tcwk9IGRhdGEtPmFjcmVnbWluICogMTAwMDsKKwkJYXJncy0+YWNy
ZWdtYXhtcwk9IGRhdGEtPmFjcmVnbWF4ICogMTAwMDsKKwkJYXJncy0+YWNkaXJtaW5tcwk9IGRh
dGEtPmFjZGlybWluICogMTAwMDsKKwkJYXJncy0+YWNkaXJtYXhtcwk9IGRhdGEtPmFjZGlybWF4
ICogMTAwMDsKIAogCQltZW1jcHkoJmFyZ3MtPm5mc19zZXJ2ZXIuYWRkcmVzcywgJmRhdGEtPmFk
ZHIsCiAJCSAgICAgICBzaXplb2YoZGF0YS0+YWRkcikpOwpAQCAtMTc3NSwxMCArMTgwOSwxMCBA
QCBuZnNfY29tcGFyZV9yZW1vdW50X2RhdGEoc3RydWN0IG5mc19zZXJ2CiAJICAgIGRhdGEtPndz
aXplICE9IG5mc3MtPndzaXplIHx8CiAJICAgIGRhdGEtPnJldHJhbnMgIT0gbmZzcy0+Y2xpZW50
LT5jbF90aW1lb3V0LT50b19yZXRyaWVzIHx8CiAJICAgIGRhdGEtPmF1dGhfZmxhdm9yc1swXSAh
PSBuZnNzLT5jbGllbnQtPmNsX2F1dGgtPmF1X2ZsYXZvciB8fAotCSAgICBkYXRhLT5hY3JlZ21p
biAhPSBuZnNzLT5hY3JlZ21pbiAvIEhaIHx8Ci0JICAgIGRhdGEtPmFjcmVnbWF4ICE9IG5mc3Mt
PmFjcmVnbWF4IC8gSFogfHwKLQkgICAgZGF0YS0+YWNkaXJtaW4gIT0gbmZzcy0+YWNkaXJtaW4g
LyBIWiB8fAotCSAgICBkYXRhLT5hY2Rpcm1heCAhPSBuZnNzLT5hY2Rpcm1heCAvIEhaIHx8CisJ
ICAgIGRhdGEtPmFjcmVnbWlubXMgIT0gKG5mc3MtPmFjcmVnbWluICogMTAwMCkgLyBIWiB8fAor
CSAgICBkYXRhLT5hY3JlZ21heG1zICE9IChuZnNzLT5hY3JlZ21heCAqIDEwMDApIC8gSFogfHwK
KwkgICAgZGF0YS0+YWNkaXJtaW5tcyAhPSAobmZzcy0+YWNkaXJtaW4gKiAxMDAwKSAvIEhaIHx8
CisJICAgIGRhdGEtPmFjZGlybWF4bXMgIT0gKG5mc3MtPmFjZGlybWF4ICogMTAwMCkgLyBIWiB8
fAogCSAgICBkYXRhLT50aW1lbyAhPSAoMTBVICogbmZzcy0+Y2xpZW50LT5jbF90aW1lb3V0LT50
b19pbml0dmFsIC8gSFopIHx8CiAJICAgIGRhdGEtPm5mc19zZXJ2ZXIuYWRkcmxlbiAhPSBuZnNz
LT5uZnNfY2xpZW50LT5jbF9hZGRybGVuIHx8CiAJICAgIG1lbWNtcCgmZGF0YS0+bmZzX3NlcnZl
ci5hZGRyZXNzLCAmbmZzcy0+bmZzX2NsaWVudC0+Y2xfYWRkciwKQEAgLTE4MTksMTAgKzE4NTMs
MTAgQEAgbmZzX3JlbW91bnQoc3RydWN0IHN1cGVyX2Jsb2NrICpzYiwgaW50CiAJZGF0YS0+d3Np
emUgPSBuZnNzLT53c2l6ZTsKIAlkYXRhLT5yZXRyYW5zID0gbmZzcy0+Y2xpZW50LT5jbF90aW1l
b3V0LT50b19yZXRyaWVzOwogCWRhdGEtPmF1dGhfZmxhdm9yc1swXSA9IG5mc3MtPmNsaWVudC0+
Y2xfYXV0aC0+YXVfZmxhdm9yOwotCWRhdGEtPmFjcmVnbWluID0gbmZzcy0+YWNyZWdtaW4gLyBI
WjsKLQlkYXRhLT5hY3JlZ21heCA9IG5mc3MtPmFjcmVnbWF4IC8gSFo7Ci0JZGF0YS0+YWNkaXJt
aW4gPSBuZnNzLT5hY2Rpcm1pbiAvIEhaOwotCWRhdGEtPmFjZGlybWF4ID0gbmZzcy0+YWNkaXJt
YXggLyBIWjsKKwlkYXRhLT5hY3JlZ21pbm1zID0gKG5mc3MtPmFjcmVnbWluICogMTAwMCkgLyBI
WjsKKwlkYXRhLT5hY3JlZ21heG1zID0gKG5mc3MtPmFjcmVnbWF4ICogMTAwMCkgLyBIWjsKKwlk
YXRhLT5hY2Rpcm1pbm1zID0gKG5mc3MtPmFjZGlybWluICogMTAwMCkgLyBIWjsKKwlkYXRhLT5h
Y2Rpcm1heG1zID0gKG5mc3MtPmFjZGlybWF4ICogMTAwMCkgLyBIWjsKIAlkYXRhLT50aW1lbyA9
IDEwVSAqIG5mc3MtPmNsaWVudC0+Y2xfdGltZW91dC0+dG9faW5pdHZhbCAvIEhaOwogCWRhdGEt
Pm5mc19zZXJ2ZXIuYWRkcmxlbiA9IG5mc3MtPm5mc19jbGllbnQtPmNsX2FkZHJsZW47CiAJbWVt
Y3B5KCZkYXRhLT5uZnNfc2VydmVyLmFkZHJlc3MsICZuZnNzLT5uZnNfY2xpZW50LT5jbF9hZGRy
LApAQCAtMjI1NCwxMCArMjI4OCwxMCBAQCBzdGF0aWMgaW50IG5mczRfdmFsaWRhdGVfbW91bnRf
ZGF0YSh2b2lkCiAKIAlhcmdzLT5yc2l6ZQkJPSBORlNfTUFYX0ZJTEVfSU9fU0laRTsKIAlhcmdz
LT53c2l6ZQkJPSBORlNfTUFYX0ZJTEVfSU9fU0laRTsKLQlhcmdzLT5hY3JlZ21pbgkJPSBORlNf
REVGX0FDUkVHTUlOOwotCWFyZ3MtPmFjcmVnbWF4CQk9IE5GU19ERUZfQUNSRUdNQVg7Ci0JYXJn
cy0+YWNkaXJtaW4JCT0gTkZTX0RFRl9BQ0RJUk1JTjsKLQlhcmdzLT5hY2Rpcm1heAkJPSBORlNf
REVGX0FDRElSTUFYOworCWFyZ3MtPmFjcmVnbWlubXMJPSBORlNfREVGX0FDUkVHTUlOX01TOwor
CWFyZ3MtPmFjcmVnbWF4bXMJPSBORlNfREVGX0FDUkVHTUFYX01TOworCWFyZ3MtPmFjZGlybWlu
bXMJPSBORlNfREVGX0FDRElSTUlOX01TOworCWFyZ3MtPmFjZGlybWF4bXMJPSBORlNfREVGX0FD
RElSTUFYX01TOwogCWFyZ3MtPm5mc19zZXJ2ZXIucG9ydAk9IE5GU19QT1JUOyAvKiAyMDQ5IHVu
bGVzcyB1c2VyIHNldCBwb3J0PSAqLwogCWFyZ3MtPmF1dGhfZmxhdm9yc1swXQk9IFJQQ19BVVRI
X1VOSVg7CiAJYXJncy0+YXV0aF9mbGF2b3JfbGVuCT0gMDsKQEAgLTIzMDYsMTUgKzIzNDAsMTUg
QEAgc3RhdGljIGludCBuZnM0X3ZhbGlkYXRlX21vdW50X2RhdGEodm9pZAogCQkgKiBjYW4gZGVh
bCB3aXRoLgogCQkgKi8KIAotCQlhcmdzLT5mbGFncwk9IGRhdGEtPmZsYWdzICYgTkZTNF9NT1VO
VF9GTEFHTUFTSzsKLQkJYXJncy0+cnNpemUJPSBkYXRhLT5yc2l6ZTsKLQkJYXJncy0+d3NpemUJ
PSBkYXRhLT53c2l6ZTsKLQkJYXJncy0+dGltZW8JPSBkYXRhLT50aW1lbzsKLQkJYXJncy0+cmV0
cmFucwk9IGRhdGEtPnJldHJhbnM7Ci0JCWFyZ3MtPmFjcmVnbWluCT0gZGF0YS0+YWNyZWdtaW47
Ci0JCWFyZ3MtPmFjcmVnbWF4CT0gZGF0YS0+YWNyZWdtYXg7Ci0JCWFyZ3MtPmFjZGlybWluCT0g
ZGF0YS0+YWNkaXJtaW47Ci0JCWFyZ3MtPmFjZGlybWF4CT0gZGF0YS0+YWNkaXJtYXg7CisJCWFy
Z3MtPmZsYWdzCQk9IGRhdGEtPmZsYWdzICYgTkZTNF9NT1VOVF9GTEFHTUFTSzsKKwkJYXJncy0+
cnNpemUJCT0gZGF0YS0+cnNpemU7CisJCWFyZ3MtPndzaXplCQk9IGRhdGEtPndzaXplOworCQlh
cmdzLT50aW1lbwkJPSBkYXRhLT50aW1lbzsKKwkJYXJncy0+cmV0cmFucwkJPSBkYXRhLT5yZXRy
YW5zOworCQlhcmdzLT5hY3JlZ21pbm1zCT0gZGF0YS0+YWNyZWdtaW4gKiAxMDAwOworCQlhcmdz
LT5hY3JlZ21heG1zCT0gZGF0YS0+YWNyZWdtYXggKiAxMDAwOworCQlhcmdzLT5hY2Rpcm1pbm1z
CT0gZGF0YS0+YWNkaXJtaW4gKiAxMDAwOworCQlhcmdzLT5hY2Rpcm1heG1zCT0gZGF0YS0+YWNk
aXJtYXggKiAxMDAwOwogCQlhcmdzLT5uZnNfc2VydmVyLnByb3RvY29sID0gZGF0YS0+cHJvdG87
CiAJCW5mc192YWxpZGF0ZV90cmFuc3BvcnRfcHJvdG9jb2woYXJncyk7CiAKSW5kZXg6IGxpbnV4
LTIuNi9pbmNsdWRlL2xpbnV4L25mc19mcy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGxpbnV4LTIuNi5vcmln
L2luY2x1ZGUvbGludXgvbmZzX2ZzLmgKKysrIGxpbnV4LTIuNi9pbmNsdWRlL2xpbnV4L25mc19m
cy5oCkBAIC0yMCwxMCArMjAsMTAgQEAKICNkZWZpbmUgTkZTX01BWF9VRFBfVElNRU9VVAkoNjAq
SFopCiAjZGVmaW5lIE5GU19NQVhfVENQX1RJTUVPVVQJKDYwMCpIWikKIAotI2RlZmluZSBORlNf
REVGX0FDUkVHTUlOCSgzKQotI2RlZmluZSBORlNfREVGX0FDUkVHTUFYCSg2MCkKLSNkZWZpbmUg
TkZTX0RFRl9BQ0RJUk1JTgkoMzApCi0jZGVmaW5lIE5GU19ERUZfQUNESVJNQVgJKDYwKQorI2Rl
ZmluZSBORlNfREVGX0FDUkVHTUlOX01TCSgzMDAwKQorI2RlZmluZSBORlNfREVGX0FDUkVHTUFY
X01TCSg2MDAwMCkKKyNkZWZpbmUgTkZTX0RFRl9BQ0RJUk1JTl9NUwkoMzAwMDApCisjZGVmaW5l
IE5GU19ERUZfQUNESVJNQVhfTVMJKDYwMDAwKQogCiAvKgogICogV2hlbiBmbHVzaGluZyBhIGNs
dXN0ZXIgb2YgZGlydHkgcGFnZXMsIHRoZXJlIGNhbiBiZSBkaWZmZXJlbnQKAAo=

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Trond Myklebust]

On Tue, 2009-06-09 at 18:32 -0700, Amit Gud wrote:
> This patch adds 4 new NFS mount options(acdirminms, acdirmaxms, acregminms,
> acregmaxms) converting already existing one into a millisecond resolution
> instead of seconds.
> 
> Also, modifies the mountstats output to milliseconds instead of seconds.

Why, exactly, do you need to control cache timeouts down to the
millisecond level?

Trond

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Amit Gud]

Trond Myklebust wrote:
> On Tue, 2009-06-09 at 18:32 -0700, Amit Gud wrote:
>> This patch adds 4 new NFS mount options(acdirminms, acdirmaxms, acregminms,
>> acregmaxms) converting already existing one into a millisecond resolution
>> instead of seconds.
>>
>> Also, modifies the mountstats output to milliseconds instead of seconds.
> 
> Why, exactly, do you need to control cache timeouts down to the
> millisecond level?
> 

The problem is to make the updates visible from one client to the other
in less than a second and turning off caching entirely has an
unacceptably high penalty.


AG
--
May the source be with you.
http://www.cis.ksu.edu/~gud

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Trond Myklebust]

On Jun 10, 2009, at 15:43, Amit Gud <agud@akamai.com> wrote:

> Trond Myklebust wrote:
>> On Tue, 2009-06-09 at 18:32 -0700, Amit Gud wrote:
>>> This patch adds 4 new NFS mount options(acdirminms, acdirmaxms,  
>>> acregminms,
>>> acregmaxms) converting already existing one into a millisecond  
>>> resolution
>>> instead of seconds.
>>>
>>> Also, modifies the mountstats output to milliseconds instead of  
>>> seconds.
>>
>> Why, exactly, do you need to control cache timeouts down to the
>> millisecond level?
>>
>
> The problem is to make the updates visible from one client to the  
> other
> in less than a second and turning off caching entirely has an
> unacceptably high penalty.

Specifics, please: updates of what, exactly? Are we talking  
attributes, data or directory contents?

What is your application, and why does 1ms constitute an acceptable  
caching timeout, while 1s does not?

Trond

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Amit Gud]

Trond Myklebust wrote:
> On Jun 10, 2009, at 15:43, Amit Gud <agud@akamai.com> wrote:
> 
>> Trond Myklebust wrote:
>>> On Tue, 2009-06-09 at 18:32 -0700, Amit Gud wrote:
>>>> This patch adds 4 new NFS mount options(acdirminms, acdirmaxms,
>>>> acregminms,
>>>> acregmaxms) converting already existing one into a millisecond
>>>> resolution
>>>> instead of seconds.
>>>>
>>>> Also, modifies the mountstats output to milliseconds instead of
>>>> seconds.
>>>
>>> Why, exactly, do you need to control cache timeouts down to the
>>> millisecond level?
>>>
>>
>> The problem is to make the updates visible from one client to the other
>> in less than a second and turning off caching entirely has an
>> unacceptably high penalty.
> 
> Specifics, please: updates of what, exactly? Are we talking attributes,
> data or directory contents?
> 
> What is your application, and why does 1ms constitute an acceptable
> caching timeout, while 1s does not?
> 

We have a system in which machine A needs a change made to an NFS
directory.  But, the actual change must be executed by machine B, so A
makes an request to B to make the update.  But, A is allowed to read
the directory directly, so A can't in general continue until it is
able to see the effect of the update.  With 1s caching, that means a
1s "sleep" after each update.

Setting caching to "0s" means that consecutive stats performed by
machine A must always revalidate every node of each path walked.  In
many cases, we end up wanting to stat every path component in some
path, which would result in O(N2) getattr or lookup calls for N
levels of directory depth.

Using a very small acdirmax (e.g. 10ms) gives us a significant
performance boost on these consecutive stats without increasing the
post-update "sleep" to 1s.  (Of course, if the file server delays more
than 10ms at any step, then we will have to start over for the next
operation.  But, the file server often has everything necessary in
cache such that each response is well below a millisecond.)


AG
--
May the source be with you.

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Trond Myklebust]

On Thu, 2009-06-11 at 13:24 -0700, Amit Gud wrote:
> Trond Myklebust wrote:
> > On Jun 10, 2009, at 15:43, Amit Gud <agud@akamai.com> wrote:
> > 
> >> Trond Myklebust wrote:
> >>> On Tue, 2009-06-09 at 18:32 -0700, Amit Gud wrote:
> >>>> This patch adds 4 new NFS mount options(acdirminms, acdirmaxms,
> >>>> acregminms,
> >>>> acregmaxms) converting already existing one into a millisecond
> >>>> resolution
> >>>> instead of seconds.
> >>>>
> >>>> Also, modifies the mountstats output to milliseconds instead of
> >>>> seconds.
> >>>
> >>> Why, exactly, do you need to control cache timeouts down to the
> >>> millisecond level?
> >>>
> >>
> >> The problem is to make the updates visible from one client to the other
> >> in less than a second and turning off caching entirely has an
> >> unacceptably high penalty.
> > 
> > Specifics, please: updates of what, exactly? Are we talking attributes,
> > data or directory contents?
> > 
> > What is your application, and why does 1ms constitute an acceptable
> > caching timeout, while 1s does not?
> > 
> 
> We have a system in which machine A needs a change made to an NFS
> directory.  But, the actual change must be executed by machine B, so A
> makes an request to B to make the update.  But, A is allowed to read
> the directory directly, so A can't in general continue until it is
> able to see the effect of the update.  With 1s caching, that means a
> 1s "sleep" after each update.
> 
> Setting caching to "0s" means that consecutive stats performed by
> machine A must always revalidate every node of each path walked.  In
> many cases, we end up wanting to stat every path component in some
> path, which would result in O(N2) getattr or lookup calls for N
> levels of directory depth.
> 
> Using a very small acdirmax (e.g. 10ms) gives us a significant
> performance boost on these consecutive stats without increasing the
> post-update "sleep" to 1s.  (Of course, if the file server delays more
> than 10ms at any step, then we will have to start over for the next
> operation.  But, the file server often has everything necessary in
> cache such that each response is well below a millisecond.)

I'm still not sure I fully understand, but here are a couple of
comments.

Firstly, opendir() will _always_ force a revalidation of the directory
attributes, so if your machine A is relying on doing an 'ls' in order to
figure out the directory contents, then that shouldn't need extra
attribute timeouts.

Secondly, we have already introduced finer control over the lookup
caching as of Linux 2.6.28 and newer:
        - if you want to ensure that machine A always see new files and
        links immediately once they have been created, then
        '-olookupcache=positive' should turn off negative dentry
        caching.
        - if you also want to ensure that it immediately sees renames,
        unlinks and such, then '-olookupcache=none' will turn off lookup
        caching altogether.
Both of these lookup cache options are more reliable than relying on the
directory attribute cache timeouts, and they have the added benefit that
they also work around the problem that Linux servers tend to have poor
mtime resolution. A 1ms cache timeout on the client won't help you much
if the server only registers changes in 1s increments.

Trond

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Amit Gud]

Trond Myklebust wrote:
> On Thu, 2009-06-11 at 13:24 -0700, Amit Gud wrote:
>> Trond Myklebust wrote:
>>> On Jun 10, 2009, at 15:43, Amit Gud <agud@akamai.com> wrote:
>>>
>>>> Trond Myklebust wrote:
>>>>> On Tue, 2009-06-09 at 18:32 -0700, Amit Gud wrote:
>>>>>> This patch adds 4 new NFS mount options(acdirminms, acdirmaxms,
>>>>>> acregminms,
>>>>>> acregmaxms) converting already existing one into a millisecond
>>>>>> resolution
>>>>>> instead of seconds.
>>>>>>
>>>>>> Also, modifies the mountstats output to milliseconds instead of
>>>>>> seconds.
>>>>> Why, exactly, do you need to control cache timeouts down to the
>>>>> millisecond level?
>>>>>
>>>> The problem is to make the updates visible from one client to the other
>>>> in less than a second and turning off caching entirely has an
>>>> unacceptably high penalty.
>>> Specifics, please: updates of what, exactly? Are we talking attributes,
>>> data or directory contents?
>>>
>>> What is your application, and why does 1ms constitute an acceptable
>>> caching timeout, while 1s does not?
>>>
>> We have a system in which machine A needs a change made to an NFS
>> directory.  But, the actual change must be executed by machine B, so A
>> makes an request to B to make the update.  But, A is allowed to read
>> the directory directly, so A can't in general continue until it is
>> able to see the effect of the update.  With 1s caching, that means a
>> 1s "sleep" after each update.
>>
>> Setting caching to "0s" means that consecutive stats performed by
>> machine A must always revalidate every node of each path walked.  In
>> many cases, we end up wanting to stat every path component in some
>> path, which would result in O(N2) getattr or lookup calls for N
>> levels of directory depth.
>>
>> Using a very small acdirmax (e.g. 10ms) gives us a significant
>> performance boost on these consecutive stats without increasing the
>> post-update "sleep" to 1s.  (Of course, if the file server delays more
>> than 10ms at any step, then we will have to start over for the next
>> operation.  But, the file server often has everything necessary in
>> cache such that each response is well below a millisecond.)
> 
> I'm still not sure I fully understand, but here are a couple of
> comments.
> 
> Firstly, opendir() will _always_ force a revalidation of the directory
> attributes, so if your machine A is relying on doing an 'ls' in order to
> figure out the directory contents, then that shouldn't need extra
> attribute timeouts.
> 
> Secondly, we have already introduced finer control over the lookup
> caching as of Linux 2.6.28 and newer:
>         - if you want to ensure that machine A always see new files and
>         links immediately once they have been created, then
>         '-olookupcache=positive' should turn off negative dentry
>         caching.
>         - if you also want to ensure that it immediately sees renames,
>         unlinks and such, then '-olookupcache=none' will turn off lookup
>         caching altogether.
> Both of these lookup cache options are more reliable than relying on the
> directory attribute cache timeouts, and they have the added benefit that
> they also work around the problem that Linux servers tend to have poor
> mtime resolution. A 1ms cache timeout on the client won't help you much
> if the server only registers changes in 1s increments.

Those options don't seem particularly useful.

Machine A doesn't necessarily use ls to figure out changes in the
directory content. So, revalidation of the directory attribute wouldn't
happen.

We definitely want lookup caching turned on, always, including both
positive and negative caching.  But, we need to see new files, unlinks,
and renames much quicker than a second.

And mtime resolution may not be a problem if NFS servers are not on Linux.


AG
--
May the source be with you.
http://www.cis.ksu.edu/~gud

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Trond Myklebust]

On Fri, 2009-06-12 at 12:30 -0700, Amit Gud wrote:
> We definitely want lookup caching turned on, always, including both
> positive and negative caching.  But, we need to see new files, unlinks,
> and renames much quicker than a second.

Then use the lookupcache option, since that's what it is for.

Trond

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Amit Gud]

Trond Myklebust wrote:
> On Fri, 2009-06-12 at 12:30 -0700, Amit Gud wrote:
>> We definitely want lookup caching turned on, always, including both
>> positive and negative caching.  But, we need to see new files, unlinks,
>> and renames much quicker than a second.
> 
> Then use the lookupcache option, since that's what it is for.
> 

Sorry, I don't understand.

Copying from your last mail:

> Secondly, we have already introduced finer control over the lookup
> caching as of Linux 2.6.28 and newer:
>         - if you want to ensure that machine A always see new files and
>         links immediately once they have been created, then
>         '-olookupcache=positive' should turn off negative dentry
>         caching.
>         - if you also want to ensure that it immediately sees renames,
>         unlinks and such, then '-olookupcache=none' will turn off lookup
>         caching altogether.

How is it possible to _not_ disable any caching (positive or negative
dentries) and still be able to see renames, unlinks and such in << 1s?


AG
--
May the source be with you.
http://www.cis.ksu.edu/~gud

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Trond Myklebust]

On Fri, 2009-06-12 at 14:49 -0700, Amit Gud wrote:
> Trond Myklebust wrote:
> > On Fri, 2009-06-12 at 12:30 -0700, Amit Gud wrote:
> >> We definitely want lookup caching turned on, always, including both
> >> positive and negative caching.  But, we need to see new files, unlinks,
> >> and renames much quicker than a second.
> > 
> > Then use the lookupcache option, since that's what it is for.
> > 
> 
> Sorry, I don't understand.
> 
> Copying from your last mail:
> 
> > Secondly, we have already introduced finer control over the lookup
> > caching as of Linux 2.6.28 and newer:
> >         - if you want to ensure that machine A always see new files and
> >         links immediately once they have been created, then
> >         '-olookupcache=positive' should turn off negative dentry
> >         caching.
> >         - if you also want to ensure that it immediately sees renames,
> >         unlinks and such, then '-olookupcache=none' will turn off lookup
> >         caching altogether.
> 
> How is it possible to _not_ disable any caching (positive or negative
> dentries) and still be able to see renames, unlinks and such in << 1s?

You could set acdirmin/acdirmax to 0, but that just floods your server
with GETATTR calls instead of LOOKUPs. Then again, so will your
millisecond acdirmin/acdirmax.
Furthermore, you would be adjusting the _attribute_ cache timeout (not
just the lookup cache), which comes at a cost to all the other
operations that depend on those attributes. IOW: readdir(), permissions
checking, stat() calls, ...

It boils down to this: I'm extremely reluctant to get into an arms race
of adding ever more mount options for increasingly finer-tuned attribute
cache timeouts. While such an option may meet _your_ machine room
requirements here and now, it becomes tiresome over the years as
machines gain power, and people first start lobbying for millisecond
timeouts, then microseconds, nanoseconds, pico... in order to catch up.

  Trond

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min,max} in milliseconds

[Amit Gud]

Trond Myklebust wrote:
> It boils down to this: I'm extremely reluctant to get into an arms race
> of adding ever more mount options for increasingly finer-tuned attribute
> cache timeouts. While such an option may meet _your_ machine room
> requirements here and now, it becomes tiresome over the years as
> machines gain power, and people first start lobbying for millisecond
> timeouts, then microseconds, nanoseconds, pico... in order to catch up.
> 

It only makes sense to make machines more powerful and put that power to
optimum use. If keeping up with increased resolution is an issue, you
think something like "-o unit=ms acregmin=..." would be better? 'unit'
can apply to all the time related options defaulting to seconds.


AG
-- 
May the source be with you.
http://cis.ksu.edu/~gud

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min, max} in milliseconds

[NeilBrown]

On Tue, June 16, 2009 8:53 am, Amit Gud wrote:
> Trond Myklebust wrote:
>> It boils down to this: I'm extremely reluctant to get into an arms race
>> of adding ever more mount options for increasingly finer-tuned attribute
>> cache timeouts. While such an option may meet _your_ machine room
>> requirements here and now, it becomes tiresome over the years as
>> machines gain power, and people first start lobbying for millisecond
>> timeouts, then microseconds, nanoseconds, pico... in order to catch up.
>>
>
> It only makes sense to make machines more powerful and put that power to
> optimum use. If keeping up with increased resolution is an issue, you
> think something like "-o unit=ms acregmin=..." would be better? 'unit'
> can apply to all the time related options defaulting to seconds.

Wasn't this problem solved hundreds of years ago by the invention
of the decimal point :-)

  -o acregmin=0.0012

Write the code to use as much precision as makes sense given the value
of HZ - and round up.  No new mount options.

NeilBrown

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min, max} in milliseconds

[Trond Myklebust]

On Tue, 2009-06-16 at 09:08 +1000, NeilBrown wrote:
> On Tue, June 16, 2009 8:53 am, Amit Gud wrote:
> > Trond Myklebust wrote:
> >> It boils down to this: I'm extremely reluctant to get into an arms race
> >> of adding ever more mount options for increasingly finer-tuned attribute
> >> cache timeouts. While such an option may meet _your_ machine room
> >> requirements here and now, it becomes tiresome over the years as
> >> machines gain power, and people first start lobbying for millisecond
> >> timeouts, then microseconds, nanoseconds, pico... in order to catch up.
> >>
> >
> > It only makes sense to make machines more powerful and put that power to
> > optimum use. If keeping up with increased resolution is an issue, you
> > think something like "-o unit=ms acregmin=..." would be better? 'unit'
> > can apply to all the time related options defaulting to seconds.
> 
> Wasn't this problem solved hundreds of years ago by the invention
> of the decimal point :-)
> 
>   -o acregmin=0.0012
> 
> Write the code to use as much precision as makes sense given the value
> of HZ - and round up.  No new mount options.

That works for me...

Trond

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min, max} in milliseconds

[Steve Dickson]

Trond Myklebust wrote:
> On Tue, 2009-06-16 at 09:08 +1000, NeilBrown wrote:
>> On Tue, June 16, 2009 8:53 am, Amit Gud wrote:
>>> Trond Myklebust wrote:
>>>> It boils down to this: I'm extremely reluctant to get into an arms race
>>>> of adding ever more mount options for increasingly finer-tuned attribute
>>>> cache timeouts. While such an option may meet _your_ machine room
>>>> requirements here and now, it becomes tiresome over the years as
>>>> machines gain power, and people first start lobbying for millisecond
>>>> timeouts, then microseconds, nanoseconds, pico... in order to catch up.
>>>>
>>> It only makes sense to make machines more powerful and put that power to
>>> optimum use. If keeping up with increased resolution is an issue, you
>>> think something like "-o unit=ms acregmin=..." would be better? 'unit'
>>> can apply to all the time related options defaulting to seconds.
>> Wasn't this problem solved hundreds of years ago by the invention
>> of the decimal point :-)
>>
>>   -o acregmin=0.0012
>>
>> Write the code to use as much precision as makes sense given the value
>> of HZ - and round up.  No new mount options.
> 
> That works for me...
Or better how about -o acregmin=12micro

steved
> 
> Trond
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] NFS: Add acreg{min,max} and acdir{min, max} in milliseconds

[Neil Brown]

On Tuesday June 16, SteveD@redhat.com wrote:
> >> Wasn't this problem solved hundreds of years ago by the invention
> >> of the decimal point :-)
> >>
> >>   -o acregmin=0.0012
> >>
> >> Write the code to use as much precision as makes sense given the value
> >> of HZ - and round up.  No new mount options.
> > 
> > That works for me...
> Or better how about -o acregmin=12micro

How can you consider that to be better?
I might almost consider "12usec" a little better as it makes the unit
explicit, and it is a fairly standard abbreviation.  But I've never
seen "micro" as a suffix before.

NeilBrown