On Fri, 08 Nov 2013 00:20:38 +0900 "ISHIKAWA,chiaki" <ishikawa@xxxxxxxxxxxx> wrote: > I am a newcomer to linux-cifs. > > Thank you for offering the great software package, which has improved > greatly over the last few years. > > I have a suggestion and a question. > > 1. Suggestion: Change the return value ENOMEM -> EREMOTEIO for an error > scenario. > > There was a discussion to changeerror code returned to user-level system > calls when the remote server providing CIFS-share > failing due to the allocation failure of non-paged resources, especially > Windows 7: > > Currently the returned errno value is ENOMEM. > > See the discussion here, for example; > http://thread.gmane.org/gmane.linux.kernel.cifs/4281 > > especially the following one: > http://article.gmane.org/gmane.linux.kernel.cifs/4303 > > The suggestion there was to change this value to EREMOTEIO. > > I wonder what came out of the discussion. > CIFS client in linux kernel still seems to return ENOMEM instead of > EREMOTEIO. > > I will go for EREMOTEIO change any time. > > ENOMEM suggests to me that there is a LOCAL resource shortage, > and it is difficult to gauge that system is telling us that there is > something missing in the remote end. > > EREMOTEIO is much better in this regard, I think. > > I wasted looking at local log files and dmesg output before > I got wiser and checked the remote Windows 7 system log when I saw > "Cannot allocate memory." message. > > By the way, EREMOTEIO is not defined in POSIX. > Under linux it is defined as > #define EREMOTEIO 121 /* Remote I/O error */ > > (at least in my copy of > Linux vm-debian-amd64 3.10-3-amd64 #1 SMP Debian 3.10.11-1 (2013-09-10) > x86_64 GNU/Linux ) > > Since linux-cifs is for linux obviously, I think it is OK to return > EREMOTEIO without bothering the conformance to POSIX here. > > Decreasing the chance of user confusion when they see the message of > "Cannot allocate memory" printed as the error message when mount fails > due to ENOMEM being returned for this error > on the remote side of the connection is more important IMHO. > Agreed. It's terribly confusing. Steve (the maintainer) seemed to be skeptical about the change, so I never actually proposed a patch. Feel free to do so, or I may do it when I get some time. > 2. Question: Can read()/write()/close() against CIFS-share return EINTR > in errno? > > This may involve a few assumptions regarding the > - mount parameter: soft (default) vs hard > - program's signal setting > > Assuming that mount parameter is soft (default), > can read/write/close end up returning EINTR in errno? > > I have seen EHOSTDOWN stored in errno by failing read() when I simulated > network error by disabling network card of a VM in which a copy of > linux runs and when it was mounting a host Windows7 CIFS-share. > (close() returned -1, too. But I forgot to record the errno value then.) > > My question is whether linux CIFS client can return EINTR in errno by > interrupted read/write/close, and if so, I think I should retry > these system calls up to a certain amount of time (so that the failure > will not block the program forever...) > Currently, there is no clear documentation about the error code returned > to the user-level system calls, and so I am asking the mailing list. > > It's not clear to me what you're asking here. EINTR implies that the process was signaled. Processes stuck in cifs code should generally respond well to SIGKILL since we do put them to sleep in such a way that they respond to that signal. Handling other signals in data-integrity codepaths is quite tricky. > > Thank you, whoever those would be, again for the improved CIFS > package. After I gave up on using CIFS under linux due to its very > slow speed against office server, I was quite pleasantly surprised > with the transfer speed this week when I tried it for the first time > in a few years. (If only my windows7 server didn't hiccup due to the > well known issue.) > Glad it's working well for you. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
