userlandfs_server: sshfs connection is broken in nightly builds

[olegkapitonov]

I make a connection to the linux server with the following commands:

mkdir /server

/system/servers/userlandfs_server sshfs

mount -t userlandfs -o 'sshfs user@…:/path' /server

On Haiku nightly builds, only viewing folder contents works (in any file manager - Tracker, Midnight Commander). When I try to copy or to open a file, the application freezes.

On r1beta4, all works normal.

[waddlesplash]

hrev56863 or hrev56886 might be the problem, please see if you can determine.

[olegkapitonov]

I have this results:

On nightly build hrev56889 (first after hrev56886 commit) all works normal. But! with old userland_fs userspace package from r4beta1 repository. With userland_fs from current master repository (and Haiku hrev56889) system drops to KDL on sshfs mounting.

And current Haiku nightly images (hrev57510 for example) drop to KDL with userland_fs package from r1beta4.

But current Haiku nightly with current userland_fs from master mounts successfully, but hangs on file copying from the sshfs share.

Maybe there is a problem with userland_fs package?

[waddlesplash]

r1beta4 userlandfs package causing KDLs on latest nightly is what I would expect, given changes to private kernel ABI (which userlandfs uses) since then. Same for using userlandfs from current master on hrev56889.

File copying hang is probably due somehow to the refactors in that commit to use the I/O routines in userlandfs; either the client or server isn't replying or communicating with the other properly.

[waddlesplash]

The read is stalling inside sshfs_read -> wait_chunk -> pthread_cond_wait, it appears.

[waddlesplash]

Actually, no, it isn't; or at least, after adding a few workarounds it isn't. Instead we have low-level CPU usage in ssh from the reads that are happening. sshfs_read returns with success, it looks like. But then I guess the request never makes it back to the kernel for some reason?

[waddlesplash]

Fixed in hrev57554.