Re: [fuse-devel] Re: ftpfs recommendations

[Miklos S. <mi...@sz...>]

> > 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?
> 
> I've done that, and it's a known issue on all of our systems.
> However, you're partially correct about the source of the problem.
> Here's the raw data on the original test system:
> ftp/rcp: 9.0 MB/s
> sftp/scp: 6.8 MB/s
> 
> Other systems with better connections get:
> rcp: 13.4 MB/s
> scp: 9.7 MB/s

I don't understand.

If CPU is the bottleneck due to en/description, then scp numbers
shouldn't vary with bandwidth change.

> > There's a known problem in sshfs with read (download) speeds in
> > certain situations, where the actual speed is well below the
> > achievable maximum.
> 
> I noticed that later and saw it on this list as well.  It turns out
> that I get the full 6.8 MB/s on writes, but about 1.8 MB/s on reads.

Yes, that's expected.

> > 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.
> 
> So to do it in userspace, would you do a readahead during the
> original roundtrip communication?

Yes.  It does some readahead, but not enough.  It's 64k (on 2.4
kernels it's less).  If RTT*bandwidth is bigger than this, then there
will be some loss of speed.  That is a 64ms max RTT for 10MB/s.  And
that includes the en/decription delays added by ssh as well as the
network delay.  So it's pretty easy to go over this limit.

> As for the FTP/encryption thing, having had a chance do a little
> more research and to sleep on it, FTP as a protocol probably
> wouldn't support every FUSE feature (I know it doesn't in LUFS).
> Probably a better approach would be use SSHFS and then (optionally,
> at user request) create a separate connection over a different port.
> Security would require that I use OpenSSL for authentication but not
> necessarily for data stream encryption.  I also suspect that not
> having to run atop SSH protocol might improve efficiency a bit as
> well.
> 
> I realize that starts to creep into FunFS land, but it's still
> fairly focused.  FunFS doesn't seem ready yet.  Anyway, if I were to
> extend SSHFS to suit my purposes here, might you be interested in
> incorporating it into your source?

Sshfs has clear goal of being able to work with the stock sftp server
supplied with the ssh server.  So you don't need to set up anything on
the server side to make it work.

Yes, it would be nice to be able to extend the protocol, but that I
think is a different project.

So unless you convince the openssh folks to include this
unencrypted-data-extension in their sftp server (unlikely), I'm
inclined not to add it to sshfs either.

Miklos