From: David-Sarah H. <dav...@ja...> - 2011-10-23 14:31:01
|
On 21/10/11 16:36, Miklos Szeredi wrote: > lu...@gn... (Ludovic Courtès) writes: >> Miklos Szeredi <mi...@sz...> skribis: >> >>> Not sure what the best permanent solution is. sshfs could validate >>> short reads by resending the read request for the remaining buffer, but >>> that seems unnecessary in most cases. Or it could resend only if >>> there's more to read according to the cached file size. >> >> I would say the former. > > The problem with that is that it could be a major performance regression > for reading small files, because it would add another network round trip > for the last read. > > The second, more hacky, option could still be a performance regression > as the file size might not be cached. And it would not be correct if > the file size changed since being cached. So I don't like it either. > > The most correct solution would be if the sftp server could declare at > startup what the largest I/O size that it can accept. SFTP has an > extension mechanism that could be used for this. So only sshfs and lshd > need to be modified and the other servers/clients can just ignore the > extension. Each version of the SFTP draft spec is clear about what it requires: In protocol [version 3], In response to this request, the server will read as many bytes as it can from the file (up to `len'), and return them in a SSH_FXP_DATA message. If an error occurs or EOF is encountered before reading any data, the server will respond with SSH_FXP_STATUS. For normal disk files, it is guaranteed that this will read the specified number of bytes, or up to end of file. For e.g. device files this may return fewer bytes than requested. In protocol [version 6], The server MUST not respond with more data than is specified by the 'length' parameter. However, the server MAY respond with less data if EOF is reached, an error is encountered, or the servers internal buffers can not handle such a large request. So if the connection had negotiated version 6 (the version that the IETF standardization process had got to before they abandoned it), lshd would have been correct to return fewer bytes. If it negotiated the more commonly implemented version 3, it is incorrect. Since sshfs only ever claims support for version 3 (see sftp_init and PROTO_VERSION in sshfs.c), the bug must be in lshd, and only lshd needs to be changed. It's unfortunate that the IETF secsh Working Group dropped the ball in failing to properly standardize SFTP, so that all current implementations would be singing from the same hymn sheet. I don't know why that happened; the reason stated in the [Wikipedia] article on SFTP doesn't seem like a good one. [version 3] https://tools.ietf.org/html/draft-ietf-secsh-filexfer-02#page-13 [version 6] https://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#page-36 [Wikipedia] https://secure.wikimedia.org/wikipedia/en/wiki/SSH_File_Transfer_Protocol#History_and_development -- David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com |