Extremely poor performance with latest stable, I/O error, random crashes on folder creation #54
Comments
|
@xnoreq how are you launching the file system? |
|
Explorer - Connect network drive: |
|
With the stable version it actually doesn't even copy the files. It's stuck in calculating... for a long time (the Explorer file copy dialog) and then when it finally starts copying the first file it fails the error element not found. |
|
Is there any way to debug/log what is going on? |
|
@xnoreq you can start sshfs from the command line and give it the option |
|
|
@xnoreq try to set the path before executing SSHFS: Also when you start SSHFS from the command-line use the options |
Still the same error. What am I doing wrong? Why does mounting work through Explorer? |
|
I switched the way primftpd accesses the filesystem on the android phone (the option is called "plain old filesystem"), and now it connects also in using sshfs.exe, but the resulting drive cannot be accessed. The security tab in explorer shows my user, nobody and everyone, but none of them have any permissions. Has anyone ever tried this with an Android phone? |
|
@xnoreq did you try setting the |
|
@billziss-gh Of course I have adjusted PATH, and no, I don't have another ssh.exe in the PATH. |
|
@xnoreq What about native sshfs under linux, have you maybe tested it before? If not, can you setup some minimal linux virtual machine and check if it works better with your android server? |
|
After some changes (using termux now on my phone) and testing using sshfs on a linux box (works fine) I get the following problems:
The folder is created however, because after closing the error and refreshing it appears in Explorer. Here is the log from creating a folder: Retry: |
|
@xnoreq sshfs-win does not currently support pubkey authentication without having to resort to the command line and/or batch files or special launchers (e.g. sirikali). Error I am assuming this happens with the latest SSHFS beta and not the stable version? |
What if it happens every time?
Correct. |
This points to a bug (access violation) in the latest beta that is easily reproducible in your environment. I am currently swamped with other work, but my intent is to sync with upstream SSHFS v3.5 before year's end; this might fix your problem. The work for this should be straightforward as all Cygwin related changes have now been incorporated upstream. So if anyone wants to take this on as a PR I would really appreciate it. |
|
Updated to latest versions today and tried again. sshfs.exe options after mount point: |
|
Btw, it works fine with sshfs 3.5.2 on a linux machine. Options are the same as above but without uid, gid. |
|
Here's the same stack trace with the x86 binary: |
|
Compiled sshfs master on cygwin with winfsp ... same crash. |
xnoreq
changed the title
|
@billziss-gh If there's any way to debug this I'd love to know how to figure out where it crashes and what exactly causes the crash. |
|
@xnoreq yes, I am aware of this problem and have seen it myself with latest SSHFS-Win beta. Unfortunately I am currently very busy with implementing low-level FUSE in WinFsp and possibly in WSLinux and have not had the chance to look at it myself. This appears to be a problem with the SSHFS code. The way I would approach it is to compile upstream SSHFS on Cygwin (this is now possible as all necessary patches have been included in the upstream project) with debug information enabled and run it under GDB until it crashes. GDB should be able to show you a complete stack trace with symbols and local variables, which would be tremendously helpful to pinpoint the problem. In the event that the problem is actually with the WinFsp FUSE3 layer rather than SSHFS, we may have to switch to WinDbg and/or Visual Studio. But I think the SSHFS/GDB investigation would give us a good idea where the problem actually lies. |
|
As I said before I've already tried upstream sshfs on cygwin. It crashes. It says it wrote a stackdump but it doesn't. I tried again with Either it didn't properly compile in debug mode or the crash is in winfsp. |
|
Using Setting a breakpoint at EDIT: line numbers are from the sshfs commit included as a git submodule to this project. |
|
@billziss-gh Thanks. After creating the folder, the first call to sshfs_getattr returns -EIO sshfs.c#L3152 because the fuse_file_info->fh (which is a struct sshfs_file *) seems to have been corrupted. The second time (e.g. when clicking retry after the I/O error dialog pops up in Explorer) sshfs_file_is_conn will succeed but sf is still corrupt. The whole backtrace: So unless sshfs randomly mangles its sshfs_file structs it looks like winfsp mangles struct fuse_file_info (at least the fh field) which it passes to |
Unfortunately the backtraces that GDB prints for WinFsp appear bogus.
Thanks for tracking this. It might be that there is a subtle difference between the rules for FUSE2 vs FUSE3 in this case. FUSE2 had both |
|
I got STATUS_ACCESS_VIOLATION on create dir at windows 10 x86_64, WinFsp-2019.2 both with new sshfs-win-3.2.18213-x64 and sshfs-win-3.5.19106-x64. But not with sshfs-win-2.7.17334-x64 |
|
Yes, this looks like this is a problem with the FUSE3 layer that newer SSHFS uses, but not with the FUSE2 layer that older SSHFS uses. |
|
Passing "-o workaround=fstat" fixes error 0x800703E3 #54 for me (WinFsp 2019.3 B1 + SSHFS-Win 3.5 BETA) |
|
@xnoreq and @temintyd thanks for the investigation and workaround respectively. I finally did some more digging into this using the Visual Studio debugger attached to During directory creation a "CREATE DIRECTORY" call is being made ( There is a clear incompatibility here. WinFsp-FUSE treats values returned in Digging into the SSHFS code we find I believe the correct action here is to take this to the libfuse and sshfs maintainer @ nikratio and have a discussion with him. While I would like to argue that
|
|
I have created experimental commit winfsp/winfsp@3a12d92 which seems to fix this problem. |
|
Nikratio is right in that the current behavior of SSHFS is correct because FUSE guarantees:
https://libfuse.github.io/doxygen/structfuse__operations.html#a1813889bc5e6e0087a936b7abe8b923f So it doesn't need to be an actual handle to a file and it should never be passed to any other functions than So here: releasedir: fsyncdir: are the only places where the I've looked at your commit. It looks like you just pass the And lastly, wouldn't it be more correct to add a "DirHandle" to |
I agree. It looks like I misunderstood how the
The existing code already had BTW, in the next day or two I will be releasing a new beta of WinFsp with this fix and other improvements, so this issue should be finally resolved. Thank you for your long patience. |
|
Thanks, it may finally be usable with sshfs for me at least.
Which brings me to the question: why didnt it crash in your case? Why
didn't you get the I/O errors?
… |
|
The SSHFS-Win Beta was actually crashing for me on Unfortunately this (WinFsp) problem was not caught by the test suites, likely because my FUSE test file systems are always written in such a way that In any case I have released the latest WinFsp beta. Give it a try if you want and let me know. https://github.com/billziss-gh/winfsp/releases I am closing this, but please reopen if the problem persists. |
Using:
Connecting to an Android phone (running primitive ftpd) over wifi results in extremely poor performance.
Copying a folder with 10 files with explorer takes like a minute just to calculate the files to copy.
Using WinSCP the files start copying instantly and with over 5 MB/s.
Using:
first resulted in an I/O error, then the drive got disconnected and stayed that way (there was no possibility to remove the faulty drive).
After mapping another drive, I again got I/O errors even just trying to create a new folder.
The text was updated successfully, but these errors were encountered: