Skip to contentSkip to conversation

4.8-rcN nfs O_DYSNC, write(2) doesn't return ENOSPC

DISCUSSION J. R. Okajima 2 participants 6 messages Sep 3, 2016 – Sep 5, 2016

Subsystems (2)
NFS client NFS server
lore
Share & tools
lore

J. R. Okajima

author
#0 lore raw

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

#1 lore raw

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

author
#2 lore raw

Trond Myklebust:

Quoted 1 line

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

author
#3 lore raw

4.8-rcN nfs, access(W_OK) on an immutable inode

In reply to 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

#4 lore raw

Re: 4.8-rcN nfs, access(W_OK) on an immutable inode

Quoted 13 lines · J. R. Okajima

=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

author
#5 lore raw

Re: 4.8-rcN nfs, access(W_OK) on an immutable inode

Trond Myklebust:

Quoted 8 lines

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