PC hang when fb2k rescan very large mp3 library
Encrypted volumes through command line
Brought to you by:
w77
Menu
▾
▴
I have 2 HD.
HD1 have OS, HD2 have a encrypted volume.
In encrypted volume have a Mp3 folder with 6000 mp3.
I use Foobar2000 and set the library to Mp3 encrypted folder.
When i rescan the library the Foobar2000 start but after a few minutes hang all the system and, "application not responding", i need the shutdown the PC from the power switch.
Not problem if use a uncrypted volume with same files.
I've also had a similar problem with Chrome browser portable, but maybe only while Foobar2000 is running, I have not tested properly.
Windows 10, ProxyCrypt 2.50 [not PowerCrypt].
Previously, with a little less files, I had no problems with Windows Seven.
Do you can test this situation?
Last edit: Mario Pilesi 2020-02-24
First, we need to clarify several points:
- PowerCrypt: is it a typo?
- "application not responding": which application? ProxyCrypt or another one? From what comes this message? Windows or your softwares?
- the encrypted volume: is it an image file or a partition? (are you using -f or -d ?)
I suspect something but I prefer first to know what is really happening on your machine, because this kind of test can take a lot of time.
Last edit: v77 2020-02-24
Last edit: Mario Pilesi 2020-02-24
OK thanks. At the very beginning of the ProxyCrypt development, when I tested the images files, I noticed that if I copied a large number of files, performances decreased regularly.
If this behavior still exists, in the extreme case, we can imagine that the system takes so much time to process new requests to the volume that some softwares and system parts can become stuck.
For compatibility purposes, images files are open in "buffered" mode. This means that when the system attempts to write something, the write request is queued.
As long as write requests are processed fast enough, the system looks responsive, but if these requests accumulate, softwares continue their operations, and the system becomes overwhelmed.
Therefore, a solution could be to switch to unbuffered mode, like with direct access to the disk (when using -d). However, this may break compatibility with storage devices with a sector size larger than 4KB (and some other strange sizes).
So I will have to add an option to restore the buffered mode for exotic hardwares.
Will you agree to try test versions?
I agree to try test versions?
If it already works in buffered mode why "So I will have to add an option to restore the buffered mode for exotic hardwares"?
You may have missed something... The buffered mode is what you are currently using through the -f switch. And it does not work so well...
However, the drawback of the unbuffered mode is that we have to use a sector size equal or multiple to the one of the storage device. And it's not obvious at all.
It can be fine to encrypt a full hard drive because most hard drives have a sector size of 512 or 4096 bytes.
But for an image file, a user can want to put it anywhere, not necessarily a hard drive, and the sector size can become strange. The worst is that the user can move the image from a device with a given sector size to a device with another sector size.
Anyway, switching the image files to the unbuffered mode should be easy, because most code of ProxyCrypt is common for -f and -d.
In fact, I have anticipated this possibility since the beginning.
So I will post here a test version very soon.
Here is a quick fix. The only risk is that the mounting fails (in this case, just switch back to the normal version), but it's very unlikely.
In the meantime, I will do extensive tests to confirm the issue and add an option in case of hardware incompatibility.
It seems to be working. I have tested with fb2k that have rescande the files without problems, also if during it got a little slower.
I cannot reproduce the issue. So, if everything still works fine for you, I will keep these parameters by default.
2.5.1 work fine, ty.