[Fwd: 1.5.11-1: sftp performance problem]

Corinna Vinschen vinschen@redhat.com
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
odd.

> 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          mailto:cygwin@cygwin.com
Red Hat, Inc.



More information about the Cygwin-patches mailing list