Closed Owyn closed 7 years ago
P.S. - any idea how to benchmark encfs performance effect on the HDD? I wanted to see how block size affects it (default is 1k, range is from 64 to 4k)...
Read results actually show bigger numbers than RAW filesystem... encfs - a way to boost hdd performance 😃
I can't seem to find the thing I'm doing wrong, it just seems encfs crashes on too-many requests at a time or something
Hi @Owyn -- it seems to be working okay on my end, running with paranoid mode:
Can you try using a 50 MB block size in CrystalDiskMark and a single pass and see if it helps? Maybe it is taking too long to write 1 GB via encfs and Dokan is timing out.
I already tried 50mb as 3rd attempt (all were 1-pass), see logs I attached if it says anything about it, have you tried my encfs settings? (not paranoid) (1st log contains encfs tome creating log)
If you still can't reproduce - could you give me a MORE debugging version or smth? windows says "encfs" program crashed, oh yes, if there is no more debugging version I could just record a dump or something, tell me what to do.
You're right that is strange -- with 4096-byte block size, the 4K read tests actually do have an improved performance! I guess because the read block sizes are the same in that setup.
Even running your settings though I am not experiencing a crash in encfs -- can you try running in paranoid mode and see if it helps the situation?
You can always try running with the Dokan debug, but you will have a lot of debugging data:
encfs.exe path mountpoint -- -d
Yes, I've just tried paranoid mode and it crashes too...
lot of debug data
yes... so console window can't hold it all, here's what it had in super-debug mode right after crash: console_log4.txt
here are windows event log related entries:
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Application Error" />
<EventID Qualifiers="0">1000</EventID>
<Level>2</Level>
<Task>100</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2016-11-14T23:28:31.935964500Z" />
<EventRecordID>1502</EventRecordID>
<Channel>Application</Channel>
<Computer>tyler</Computer>
<Security />
</System>
- <EventData>
<Data>encfs.exe</Data>
<Data>0.0.0.0</Data>
<Data>581cc830</Data>
<Data>encfs.exe</Data>
<Data>0.0.0.0</Data>
<Data>581cc830</Data>
<Data>c0000005</Data>
<Data>00023347</Data>
<Data>1118</Data>
<Data>01d23ecea5c3efdb</Data>
<Data>S:\Program Files (x86)\encfs\encfs.exe</Data>
<Data>S:\Program Files (x86)\encfs\encfs.exe</Data>
<Data>5fdaf6a0-fd3b-4c20-ad67-e46f6a71b7fa</Data>
<Data />
<Data />
</EventData>
</Event>
and
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
<Provider Name="Windows Error Reporting" />
<EventID Qualifiers="0">1001</EventID>
<Level>4</Level>
<Task>0</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2016-11-14T23:28:38.723011200Z" />
<EventRecordID>1503</EventRecordID>
<Channel>Application</Channel>
<Computer>tyler</Computer>
<Security />
</System>
- <EventData>
<Data>108561366874</Data>
<Data>1</Data>
<Data>APPCRASH</Data>
<Data>Нет данных</Data>
<Data>0</Data>
<Data>encfs.exe</Data>
<Data>0.0.0.0</Data>
<Data>581cc830</Data>
<Data>encfs.exe</Data>
<Data>0.0.0.0</Data>
<Data>581cc830</Data>
<Data>c0000005</Data>
<Data>00023347</Data>
<Data />
<Data />
<Data>\\?\S:\ProgramData\Microsoft\Windows\WER\Temp\WERE70D.tmp.WERInternalMetadata.xml</Data>
<Data>S:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_encfs.exe_64b8fab91e060f94f973f84abe5234764f64a9d_bd99a068_0eff011d</Data>
<Data />
<Data>0</Data>
<Data>5fdaf6a0-fd3b-4c20-ad67-e46f6a71b7fa</Data>
<Data>0</Data>
<Data>c33bf40e3f045971c34bac3dc1e23e4e</Data>
</EventData>
</Event>
@Owyn -- On my end I can reproduce (intermittently) a bug where CrystalDiskMark fails before starting the writing tests (likely a Dokany bug), but I have not been able to make encfs crash. My test machine is Windows 7, so it's possible that this is causing a crash in Windows 10 (and not 7) for some reason though.
I need to discuss with the Dokany developers and see what we can do, and if this fixes the issue on both of our machines.
@Owyn -- it seems that you can work around this issue for the time being by using single-threaded mode (add the "-s" flag to the command line). There seems to be a race condition in Dokany that is causing the program to fail in multi-threaded mode.
I've tested copying a large amount of files with the FreeFileSync program to an enfs4win drive (paranoid mode) under Windows 7, and I quickly get a crash as well. Easily repeatable. That's with or without single-threaded mode.
For now I don't have a log or a stack trace. Other possibly relevant info:
@gab -- this might be related to https://github.com/jetwhiz/encfs4win/issues/75
Can you test and see if g-stefan's fix takes care of your issue?
@gab -- can you check if the latest version of encfs4win fixes this issue? https://github.com/jetwhiz/encfs4win/releases/tag/v1.10.1-RC11
@jetwhiz I finally got time to stress test v1.10.1-RC11 a bit, and I'm happy to report that it now happily accepts a transfer of 15+ GBs of files including 3+ GBs individual files without problems on my end (paranoid mode, default settings otherwise). Thanks for fixing the issue.
That's great news, @gab -- thanks for the update!
Environment
Description
So I made a test folder, wanted to test how encryption affects disk performance... ran the test and ENCFS just crashed
Expected behavior vs. actual behavior
It mustn't crash
Steps to reproduce problem
2 of 3 times - it crashed after passing read tests and starting write ones 1 of 3 times - it crashed right away before reading tests
P.S. - I think I did something wrong, but some random app might do it accidentally too and crash the running encfs which is bad
Relevant logs
-v -f console_log.txt
console_log2and3.txt