[Fwd: 1.5.11-1: sftp performance problem]
Sun Sep 12 14:42:00 GMT 2004
On Sep 11 14:20, Bob Byrnes wrote:
> When the inbound transfer stalls, I see sftp performing a blocking
> read on the ssh->sftp pipe. It seems to be reading 16k chunks (even
> though the default buffer size is supposed to be 32k ... see below).
> ssh is using select to monitor both pipes and the socket, but the
> ssh->sftp pipe doesn't select writable for long periods of time,
> because NtQueryInformationFile reports that the pipe is full.
> That's odd: why isn't the data in transit within the pipe delivered
> to the reading sftp process?
Do I understand that right? sftp is in the blocking read on the pipe,
there is data in the pipe and nevertheless read doesn't return? That's
> But the docs also say that "Write-through mode ... affects only write
> operations on byte-type pipes and, then, only when the client and server
> processes are on different computers." I guess this means that local
> pipes always do buffering as described in the previous paragraph, and
> this can't be disabled using FILE_FLAG_WRITE_THROUGH.
Did you try that?
> So, what should we do now? We need a reliable way to tell if writes
> will block, for both select and nonblocking I/O. I've been using
> NtQueryInformationFile to see how much space is available (analogous
> to use of PeekNamedPipe for reads), but we need to control how pipe
> buffering is done.
> I'll do some experiments ... maybe we can use something like FlushFileBuffers
> before NtQueryInformationFile to induce data transfer to any pending reads on
> the other side of the pipe, although I'm concerned that this might block
> when there is no pending read, and that would be bad.
> Other, better ideas would be most welcome!
Dunno if that's a *better* idea, but would it be reasonable to try changing
pipes to use overlapped I/O? Or what if a read from a pipe always asks for
the number of available bytes using NtQueryInformationFile and then only
actually reads this number of bytes and returns that to the caller?
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader mailto:email@example.com
Red Hat, Inc.
More information about the Cygwin-patches