SUMMARY After mounting the vault I get the following notification: "Filesystem is not responding: filesystem mounted at '<path>' is not responding." Trying to access it through dolphin causes dolphin to become completely stuck (terminating doesn't work, not even with `kill -9`). This could be a similar problem to the unresolved bug #409494. After a long time the directory becomes accessible but very slow. On one occasion it even caused a complete system freeze that required a hard reboot (very long time with no response, even REISUB failed). Trying to unmount the vault during the long period of time (circa 20-30 minutes) that it is unresponsive gives an error in the vaults applet ("device is being used by another application" or something of the sort) and the mount/unmount icon toggles at a very high frequency until it is resolved. STEPS TO REPRODUCE 1. Create a vault with the base directory and mount point located in a custom location outside the OS's HD. 2. Copy a large number of files weighing a couple of hundreds of GBs into the vault. 3. Mount vault and try to access. OBSERVED RESULT Dolphin freezes, vault is inaccessible, it is impossible to unmount vault. EXPECTED RESULT Vault is promptly mounted and contained data is accessible. Unmounting is possible on command. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 19.10 (available in About System) KDE Plasma Version: 5.16.5 KDE Frameworks Version: 5.62.0 Qt Version: 5.12.4 ADDITIONAL INFORMATION cryfs encoding scheme. Large number of files (altogether ~400GB, if that could be relevant). Also, the base directory as well as the mount point are not on the main SSD hard-drive on which the OS is installed, but on a separate HDD. Using cryfs to access the directory in the terminal works fine.
Exact same issue. Kubuntu 20.04. Large cryfs (100GB+) become unresponsive for several minutes after mounting. Causes dolphin to freeze for long periods.
Hi all, This is something that needs to be reported upstream. It would be great if you have the time to do so and provide the cryfs authors with feedback / more information they might need.
Cryfs is not the issue. The issue is dolphin and any large ecrypted filesystem. I get similar behavior with veracrypt volumes mounted using zulucrypt. Dolphin has consistently takes a dive anytime a new filesystem device is suddenly mounted with hundreds of thousands of files.
@Ken You can open a separate bug report on Dolphin. Dolphin is not to blame for "Filesystem is not responding" reported by Zvi. There have been reports here of cryfs being blocked even in terminal. So, nothing to do with Dolphin.
@Ivan I can confirm after switching to Veracrypt I had no problem using Dolphin, so the problem indeed does not seem to be related to it. Just to make sure I understood correctly - I should open an issue in cryfs (https://github.com/cryfs/cryfs)?
@Zvi Yes, please :)
(In reply to Ivan Čukić from comment #4) > @Ken > > You can open a separate bug report on Dolphin. > > Dolphin is not to blame for "Filesystem is not responding" reported by Zvi. > There have been reports here of cryfs being blocked even in terminal. So, > nothing to do with Dolphin. Looks like you're correct about it not being Dolphin. Hang issue is still present using Krusader as well. Thank you.
@Ken You should try from the terminal - when dolphin/krusader get blocked, test whether you can open some file in vim or another console editor. If that works, then you might be experiencing an issue that *is* somewhere in KDE (I assume krusader uses the same underlying libraries as dolpgin, though I might be mistaken)
Reported in cryfs. Link for future reference: https://github.com/cryfs/cryfs/issues/346
(In reply to Ivan Čukić from comment #8) > @Ken > > You should try from the terminal - when dolphin/krusader get blocked, test > whether you can open some file in vim or another console editor. If that > works, then you might be experiencing an issue that *is* somewhere in KDE (I > assume krusader uses the same underlying libraries as dolpgin, though I > might be mistaken) @Ivan - will do. Thanks for the suggestion. @Zvi - apologies for muddying the waters on your ticket.
As the cryfs report notes, this problem can be mitigated by choosing a larger block size by default. Assuming it works, it sounds like a good solution we can implement in KDE. Reopening.