[PATCH] Improving sftp client performance

[Tobias Ringstrom]

On Sat, 5 Jan 2002, Dan Kaminsky wrote:

>     I'm a little wary of what's going on at the hard drive level.  Clever
> file system tricks aside, it's *always* faster to read and write sequential
> blocks of data.  Might there be any coalescing of requests on the server
> level?

The openssh sftp client will always upload file blocks in sequence.  
There is one case in my patch where we will issure read request packets
out of sequence.  It happens when we have two outstanding read requests of
8192 byte each, and the first returns with less than the requested amount
of data.  In this case we will read the missing data out of sequence.  
Note that this only happens for servers that cannot handle 8192 byte
reads.  I could fix that by reducing the size of the requested blocks, but
I doubt we will need that since the blocks are so small already.

Another case is if the remote server reorders the responses to our read
requests.  If that happens we will not write to the file sequentially.  
The openssh sftp server does not reorder responses, but if need arises,

Or are you saying that the block size should be greater than 8192 bytes?

>     Also, I think it was mentioned that the overlapping techniques are only
> being used for blocks within one file.  It's *very* common to need to copy
> vast numbers of small files from one location to another, and finding
> efficient means of doing so can sometimes be challenging.  It's something to
> keep in mind.

Correct, but I doubt the openssh sftp client is, or ever will be, the tool
for that.

/Tobias