search

jetwhiz / encfs4win

Windows port of EncFS
https://encfs.win
Other
400 stars 41 forks source link

ENCFS crash on crystaldiskmark writing test into mount dir #64

Closed Owyn closed 7 years ago

Owyn commented 7 years ago

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

  1. Use encfs: test folder with encrypted files V: mount drive with unencrypted output files
  2. run crystaldiskmark test on V: mount drive
  3. crash

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

4 _proc

Owyn commented 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

jetwhiz commented 7 years ago

Hi @Owyn -- it seems to be working okay on my end, running with paranoid mode:

virtualbox_win7_14_11_2016_15_45_55

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.

Owyn commented 7 years ago

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.

jetwhiz commented 7 years ago

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.

virtualbox_win7_15_11_2016_00_00_52

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
Owyn commented 7 years ago

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

Owyn commented 7 years ago

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>
jetwhiz commented 7 years ago

@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.

jetwhiz commented 7 years ago

@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.

gab commented 7 years ago

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:

jetwhiz commented 7 years ago

@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?

jetwhiz commented 7 years ago

@gab -- can you check if the latest version of encfs4win fixes this issue? https://github.com/jetwhiz/encfs4win/releases/tag/v1.10.1-RC11

gab commented 7 years ago

@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.

jetwhiz commented 7 years ago

That's great news, @gab -- thanks for the update!