|
From: Miklos S. <mi...@sz...> - 2006-01-05 09:24:14
|
> Unfortunately, I work at a site with strict security requirements > such that all SSH data streams including file transfers are > encrypted. However, we do have a specially modified Kerberos > implementation with an ftp client that can encrypt the > authentication and control streams but not necessarily the data > streams. This results in a 2-3x speedup, depending upon the systems > involved (connection bandwidth, processor speeds, etc.). I know it > may sound silly, but the situation is unlikely to change anytime > soon. My I ask how did you do the benchmarking? Can you try comparing the speed of ftp vs. scp (instead of sshfs) in both directions? There's a known problem in sshfs with read (download) speeds in certain situations, where the actual speed is well below the achievable maximum. This could be fixed purely in userspace, but a much simpler solution would be to do it with the help of the kernel readahead logic. There's some barriers to that however: currently deadlocks are made breakable by doing all requests synchronously. But for readahead to work effectively, the read requests would have to be asynchronous. I'm thinking about how to solve the deadlock problem in a different way that would allow async requests. Miklos |