Hello NFS folks,
I am not subscribing this ML. Please CC to me explicitly when you reply.
I found a problem of NFS in linux-v4.8-rc[123]. Here is a reproducible
sequence.
- mount a rather small tmpfs, for example /tmp/srvr
- export it to localhost
- mount localhost:/tmp/srvr /tmp/clnt
- dd if=/dev/zero of=/tmp/clnt/full
After a while, dd ends with ENOSPC expectedly. But if I add "oflag=dsync"
to dd(1), it never ends. strace(1) shows dd repeats write(512bytes) and
gets the value 512.
If this is a known issue, please tell me the commit id of the fix.
J. R. Okajima
T24gU2F0LCAyMDE2LTA5LTAzIGF0IDEzOjMxICswOTAwLCBKLiBSLiBPa2FqaW1hIHdyb3RlOg0K
PiBIZWxsbyBORlMgZm9sa3MsDQo+IA0KPiBJIGFtIG5vdCBzdWJzY3JpYmluZyB0aGlzIE1MLiBQ
bGVhc2UgQ0MgdG8gbWUgZXhwbGljaXRseSB3aGVuIHlvdQ0KPiByZXBseS4NCj4gDQo+IEkgZm91
bmQgYSBwcm9ibGVtIG9mIE5GUyBpbiBsaW51eC12NC44LXJjWzEyM10uIEhlcmUgaXMgYQ0KPiBy
ZXByb2R1Y2libGUNCj4gc2VxdWVuY2UuDQo+IA0KPiAtIG1vdW50IGEgcmF0aGVyIHNtYWxsIHRt
cGZzLCBmb3IgZXhhbXBsZSAvdG1wL3NydnINCj4gLSBleHBvcnQgaXQgdG8gbG9jYWxob3N0DQo+
IC0gbW91bnQgbG9jYWxob3N0Oi90bXAvc3J2ciAvdG1wL2NsbnQNCj4gLSBkZCBpZj0vZGV2L3pl
cm8gb2Y9L3RtcC9jbG50L2Z1bGwNCj4gDQo+IEFmdGVyIGEgd2hpbGUsIGRkIGVuZHMgd2l0aCBF
Tk9TUEMgZXhwZWN0ZWRseS4gQnV0IGlmIEkgYWRkDQo+ICJvZmxhZz1kc3luYyINCj4gdG8gZGQo
MSksIGl0IG5ldmVyIGVuZHMuIHN0cmFjZSgxKSBzaG93cyBkZCByZXBlYXRzIHdyaXRlKDUxMmJ5
dGVzKQ0KPiBhbmQNCj4gZ2V0cyB0aGUgdmFsdWUgNTEyLg0KPiANCj4gSWYgdGhpcyBpcyBhIGtu
b3duIGlzc3VlLCBwbGVhc2UgdGVsbCBtZSB0aGUgY29tbWl0IGlkIG9mIHRoZSBmaXguDQo+wqAN
Cg0KVGhhbmtzIGZvciB0ZXN0aW5nISBEb2VzIHRoZSBmb2xsb3dpbmcgcGF0Y2ggZml4IHRoZSBp
c3N1ZSBmb3IgeW91Pw0KDQpDaGVlcnMNCsKgIFRyb25kDQoNCjg8LS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRnJvbSBjNDll
ZGVjZDUxMzY5M2VhNzUzMGFiMThlZmJkN2Q2ZDViN2NiZjkwIE1vbiBTZXAgMTcgMDA6MDA6MDAg
MjAwMQ0KRnJvbTogVHJvbmQgTXlrbGVidXN0IDx0cm9uZC5teWtsZWJ1c3RAcHJpbWFyeWRhdGEu
Y29tPg0KRGF0ZTogU2F0LCAzIFNlcCAyMDE2IDEyOjA1OjMxIC0wNDAwDQpTdWJqZWN0OiBbUEFU
Q0hdIE5GUzogRml4IGVycm9yIHJlcG9ydGluZyBpbiBuZnNfZmlsZV93cml0ZSgpDQoNCldoZW4g
ZG9pbmcgT19EU1lOQyB3cml0ZXMsIHRoZSBhY3R1YWwgd3JpdGUgZXJyb3JzIGFyZSByZXBvcnRl
ZCB0aHJvdWdoDQpnZW5lcmljX3dyaXRlX3N5bmMoKSwgc28gd2UgbXVzdCB0ZXN0IHRoZSByZXN1
bHQuDQoNClJlcG9ydGVkLWJ5OiBKLiBSLiBPa2FqaW1hIDxob29hbm9uMDVnQGdtYWlsLmNvbT4N
CkZpeGVzOiAxODI5MDY1MGIxYzggKCJORlM6IE1vdmUgYnVmZmVyZWQgSS9PIGxvY2tpbmcgaW50
byBuZnNfZmlsZV93cml0ZSgpIikNClNpZ25lZC1vZmYtYnk6IFRyb25kIE15a2xlYnVzdCA8dHJv
bmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbT4NCi0tLQ0KIGZzL25mcy9maWxlLmMgfCA1ICsr
KystDQogMSBmaWxlIGNoYW5nZWQsIDQgaW5zZXJ0aW9ucygrKSwgMSBkZWxldGlvbigtKQ0KDQpk
aWZmIC0tZ2l0IGEvZnMvbmZzL2ZpbGUuYyBiL2ZzL25mcy9maWxlLmMNCmluZGV4IDdkNjIwOTcw
ZjJlMS4uY2E2OTlkZGMxMWMxIDEwMDY0NA0KLS0tIGEvZnMvbmZzL2ZpbGUuYw0KKysrIGIvZnMv
bmZzL2ZpbGUuYw0KQEAgLTY1Nyw3ICs2NTcsMTAgQEAgc3NpemVfdCBuZnNfZmlsZV93cml0ZShz
dHJ1Y3Qga2lvY2IgKmlvY2IsIHN0cnVjdCBpb3ZfaXRlciAqZnJvbSkNCiAJaWYgKHJlc3VsdCA8
PSAwKQ0KIAkJZ290byBvdXQ7DQogDQotCXdyaXR0ZW4gPSBnZW5lcmljX3dyaXRlX3N5bmMoaW9j
YiwgcmVzdWx0KTsNCisJcmVzdWx0ID0gZ2VuZXJpY193cml0ZV9zeW5jKGlvY2IsIHJlc3VsdCk7
DQorCWlmIChyZXN1bHQgPCAwKQ0KKwkJZ290byBvdXQ7DQorCXdyaXR0ZW4gPSByZXN1bHQ7DQog
CWlvY2ItPmtpX3BvcyArPSB3cml0dGVuOw0KIA0KIAkvKiBSZXR1cm4gZXJyb3IgdmFsdWVzICov
DQotLSANCjIuNy40DQotLSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWlu
dGFpbmVyLCBQcmltYXJ5RGF0YQ0KdHJvbmQubXlrbGVidXN0QHByaW1hcnlkYXRhLmNvbQ0K
Trond Myklebust:
> Thanks for testing! Does the following patch fix the issue for you?
Thank you for quick response and the patch.
It worked!
J. R. Okajima
Hello again,
linux-v4.8-rcN has a commit
337684a 2016-08-07 fs: return EPERM on immutable inode
I am afraid NFS should follow the same behaviour. In other words,
fs/nfs/dir.c:nfs_do_access() should return -EPERM when MAY_WRITE on an
immutable inode. Currently it returns EACCES.
J. R. Okajima
> On Sep 5, 2016, at 13:19, J. R. Okajima <[email protected]> wrote:
>=20
>=20
> Hello again,
>=20
> linux-v4.8-rcN has a commit
> =09337684a 2016-08-07 fs: return EPERM on immutable inode
>=20
> I am afraid NFS should follow the same behaviour. In other words,
> fs/nfs/dir.c:nfs_do_access() should return -EPERM when MAY_WRITE on an
> immutable inode. Currently it returns EACCES.
>=20
The NFS protocol has no way to convey to the client that the inode is label=
ed as immutable on the server. The NFSv4.1 =93retention_hold=94 mechanism d=
escribed in RFC5661 comes close, and could possibly be used, but it is not =
implemented for now.
Note also that file immutability is not a POSIX concept, and EPERM is conse=
quently not listed as one of the POSIX sanctioned return values for access(=
): http://pubs.opengroup.org/onlinepubs/9699919799/functions/access.html
Cheers
Trond
Trond Myklebust:
> The NFS protocol has no way to convey to the client that the inode is label=
> ed as immutable on the server. The NFSv4.1 =93retention_hold=94 mechanism d=
> escribed in RFC5661 comes close, and could possibly be used, but it is not =
> implemented for now.
>
> Note also that file immutability is not a POSIX concept, and EPERM is conse=
> quently not listed as one of the POSIX sanctioned return values for access(=
> ): http://pubs.opengroup.org/onlinepubs/9699919799/functions/access.html
Ok.
Thanx for the explanation.
J. R. Okajima