Re: [sshfs] Regarding sshfs and lshd

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

ni...@ly... (Niels Möller) writes:

> Hi,
>
> I'm the main author of lshd and its sftp-server program. I've read part of
> the recent "SSHFS vs. GNU lshd" thread after Ludivoc Courtès mailed me a
> related lsh bug report.
>
> I have to plead a bit of ignorance; I'm rarely using sftp myself, and
> I'm not at all familiar with fuse. I don't think I have touched that
> sftp-server program since back in 2002, and in the mean time I have
> forgotten a lot of the details in the sftp protocol...
>
> Anyway, I have a couple of comments and a few questions.
>
> 1. lshd's sftp-server implements version 3 of the sftp protocol.
>
> 2. It currently clamps the size for read requests to 32 KB. That's
>    clearly broken, in that clients asking for larger reads will conclude
>    that they have reached EOF. I think that bug is the source of the
>    reported problem.
>
> 3. Nevertheless, I want to keep some, pretty arbitrary, limit on read
>    request size: If I get a read request for 17 GB, I don't want to
>    allocate a message buffer of that size, I'd prefer to let the
>    operation fail, and return some error code. Advice on what limit may
>    be reasonable, and what kind of error should be returned when it is
>    exceeded, is highly appreciated.

OpenSSH is the de-facto standard and so I'd go with the same limits as
they do:

sftp-common.h:#define SFTP_MAX_MSG_LENGTH       (256 * 1024)

>
> 4. I don't think it is very polite for sftp clients to make very large
>    read requests, since that will force the server side to allocate a
>    large message buffer.
>
>    If you get a 64 KB request from the kernel (and lets assume for the
>    moment that 64 KB can be considered "large"), then you can split that
>    into two read requests of 32 KB. As far as I understand, doing that
>    does *not* require any extra network roundtrip: You can send both
>    requests back-to-back over the network (they'll most likely even fit
>    in the same TCP segment). Maybe that's what your -omax_read option
>    does already?

Yes, that is what will happen.

>  I guess one may need to think about what to do in the
>    unlikely case that the first request fails but the second for some
>    reason succeeds.

It will result in the Linux kernel retrying the read in page size chunks
and so reporting the exact point where the failure occurs.

> 5. Even if lshd's sftp-server's current limit of 32 KB may be
>    ridiculously small, you may want to consider server implementations
>    on more constrained devices. And I doubt you get any measurable
>    performance gain by sending one 64 KB request rather than two 32 KB
>    requests or even eight 8 KB requests (although I'd be happy to hear
>    about such benchmarks).

The problem is that it's difficult to distinguish a short read due to
EOF and a short read due to a constrained device.  Or more precisely it
is difficult to distinguish those cases without sacrificing performance
in the common case.

> 6. Regarding the ietf work on sftp, my understanding is as follows:
>    Originally, sftp was a fairly simple unix-centric protocol: Files are
>    byte sequences, filenames are byte sequences, operations correspond
>    more or less directly to common unix/posix syscalls. The final years
>    of sftp discussion in the ietf secsh working group was about support
>    for features such as text vs binary file modes, line end convention
>    negotiation for text files, various types of ACLs, file name
>    character sets, etc. Even a more complex version handshake (for
>    proper fallback to version 3 in the unlikely case that an
>    implementations supporting version 3 and 4 wants to talk to an
>    implementation supporting version 3 and version 6, but no
>    intermediate versions; I consider that totally wasted, since I don't
>    expect any deployed implementation to support version 4 without also
>    supporting version 6). So sftp was on the path to becoming a complex
>    "enterprise-ready" comittee-designed protocol.
>
>    But then none of the people involved had sufficient time and energy
>    to get that more ambitious protocol completed in a reasonable time.
>    So shortly after the the core ssh specificatinos finally reached rfc
>    status, the work group was formally concluded. Any new sftp
>    specification would have to be made as an individual submission
>    rather than a wg product. The ietf-secsh mailing list is still open,
>    and sftp discussions are on topic there.
>
> 7. And finally, one question: Is there some maximum size of the read
>    requests fuse-sshfs will ever send? E.g., is it at all possible to
>    make a one GB read call to the kernel (say, some kind of non-cached
>    disk access or a read from /dev/zero), and have that translated into
>    a one GB request over the fuse interface, and further translated to a
>    one GB sftp read request?

Currently sshfs will not send an I/O request larger than 64k.  If there
was a way to negotiate the max request size, that limit could be
adjusted automatically.

>
> 8. I think the considerations for write request size are similar
>    (although it may be possible for a careful server to support very
>    large writes without allocating a large message buffer).
>
> I'd like to fix the problem properly (and I don't think a i/o-size
> protocol extension is necessary, even though that would fit perfectly in
> a spec for sftp version 7...).

IMHO the simplest and safest fix is to go with the OpenSSH limit.

Thanks,
Miklos