On 2013-12-04 14:33, Antti Tönkyrä wrote:
On 2013-12-03 23:22, Dr Fields James Bruce wrote:
On Tue, Dec 03, 2013 at 03:48:06PM -0500, Dr Fields James Bruce wrote:
OK, it makes sense that touching a file with a bad name would get an
error, but you're seeing that cause later creates of files on the same
filesystem fail. I can't figure out why that would happen.
...
So maybe there's some other problem here, but...
Given that widely used ntfs-3g FUSE module also returns EILSEQ on
the same case (I tested this) I would argue that a fix should be
done for upstream especially since RFC5661 clearly defines that
invalid UTF-8 sequence should map into NFSERR_INVAL, exact quote:
"Where the client sends an invalid UTF-8 string, the server
should return NFS4ERR_INVAL (see Table 5)".
The NFS client will then happily map that straight into EINVAL for
you...
This seems like a spec bug?
NFS4ERR_INVAL only makes sense if you could really mandate UTF-8 on the
wire all the time. But I don't know what other error would work.
I guess a client could map INVAL to EILSEQ on open or lookup (is there
any other reason a correct client should ever see INVAL on those ops?).
Or do that only if fs_charset is supported and has
FSCHARSET_CAP4_ALLOWS_ONLY_UTF8 set. Yuch.
--b.
Ewh...
I did some further testing and managed to get stale NFS file handles
instead of I/O errors on one run. (Haven't been able to repeat this
behaviour)
After that I did another run (which errored with I/O errors) and found
out that I am able to touch existing files but not create any new
files. Touching an existing file changes the mtime as expected on both
the NFS share and backing FS so something is still being exchanged by
the NFS client and server. I also tested to write into a touchable
file but that returned an I/O error again.
Example below:
# ls -l p
-rwxrwxrwx 1 root root 0 Dec 4 14:26 p
# touch p
# ls -l p
-rwxrwxrwx 1 root root 0 Dec 4 14:31 p
# touch newfile
touch: cannot touch `newfile': Input/output error
# echo test > p
-su: p: Input/output error
- Antti
Also might be worth noting that NFSv3 also emits the "nfsd: non-standard
errno: -84" and touch command on client says "I/O error" but in NFSv3
case the client doesn't start to I/O erroring on everything after that.
- Antti
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
