If sshfs is mounted with "-o direct_io" on FreeBSD and a large write
call is passed to the fs, then it will get stuck.
What do I mean by large? Exactly 73699 bytes. All's fine with 73698...
I tracked down that the stuck occurs in the writev() call of
do_write() in sshfs.c.
- FreeBSD has three threading libraries, the problem seems to cease with
the purely userspace one (libc_r). Alas, libc_r doesn't work reliably
on recent FBSD releases, so I neither can state that an app works
reliably with it (I do need some woodoo to get sshfs working with
libc_r, so it's strange from the start).
- If I replace sshfs.outfd with a socket instead of a pipe -- ie.,
I replace "pipe(outpipe)" with
"socketpair(AF_UNIX, SOCK_STREAM, 0, outpipe)" in start_ssh() --
again, the problem goes away.
It much rather seems to be a bug in FreeBSD than in FUSE/sshfs, I just
wonder if you have any notice about it... do you do anything related to
threads/pipes which could cause this? Or could you suggest a strategy
for getting to a trimmed down proof-of-concept case? I'm afraid that
if I post this problem to some FBSD ml as-is, people will jump over it,
because first they should understand how sshfs work before they could do
anything about it...
OTOH, AFAICS both the inpipe and the outpipe pairs could be replaced
with a single socketpair. That would solve the problem (even if it
didn't let us see the reason of the bug). Wouldn't such a transition be
a desired simplification, regardless of this issue? Would it have an
evident effect on performance?
> OTOH, AFAICS both the inpipe and the outpipe pairs could be replaced
> with a single socketpair. That would solve the problem (even if it
> didn't let us see the reason of the bug). Wouldn't such a transition be
> a desired simplification, regardless of this issue? Would it have an
> evident effect on performance?
Since it's a simplification, as well as a fix for the above problem it
makes sense IMO.