16 replies to this topic

[v77]

I have some questions about this new version.
First of all, what happened to the 1.8.1? Disappeared in a black hole?

About "Cache latest I/O block": how does it work? Is it used only for read requests? What is the size of this cache, especially when a proxy is used? Is this cache cleaned when the volume is unmounted?

By the way, you did not fixed the second typo that I notified you: "Default values depends" in "-y tracks/cylinder"...

[Olof Lagerkvist]

By the time I was ready with the -P command line switch for registry settings, I was also pretty much ready with the driver related changes. Driver changes take a lot more time to test, but before I could run those tests I had to build a version for a user who needed the -P command line switch. So, I gave that intermediate build version number 1.8.1. There were only a few days between them, though. So I thought that one single official release with both changes was most reasonable, even if it caused a gap in version numbering.

 

The I/O block cache does not affect proxy communication or anything like that, this works a couple of levels above such communication. It is related to the functions that dispatches I/O requests sent to ImDisk driver. The driver uses an intermediate non-pageable buffer when sending requests down to underlying storage (image file, proxy, etc). This buffer is just a copy of the buffer sent to ImDisk driver in the first place. The change now is that after a successful read or write operation, this intermediate buffer is now kept in memory, so that if next received read request is located within the range of this buffer, the driver responds using this buffer directly in the dispatch routine. It does not even need to schedule any work for the worker thread used by this virtual disk. The buffer memory is automatically freed when the virtual disk drive is removed.

 

Sorry that I missed one of the typos you mentioned, I will fix that!

[v77]

Thanks. In fact, with my last question, I was thinking about a possible security issue (for instance with my ProxyCrypt). But finally, it's not different than the file buffering done by the system...

[Olof Lagerkvist]

I see. Yes, that could be something to notice when using encryption. But this particular buffer, I would say, is not a problem. It is in non-paged kernel pool memory and is no different compared to the buffers that are anyway used in the communication between filesystem driver and ImDisk driver.

What could be worse, but probably not practically an issue, could be the shared memory communication between ImDisk driver and the proxy service. That is difficult to protect from interception by other service applications or drivers. For a process running under system account, all it takes is to open the shared memory block by name (using OpenFileMapping/MapViewOfFile). It could probably add some protection to use TCP/IP communication instead. But on the other hand, such communication can be intercepted by filter drivers and even user mode filtering modules under certain circumstances.

[draisp]

Let me reuse this thread to report about 1.8.2 that the browser cache I set for a Gecko browser to an ImDisk virtual disk stopped working correctly under Windows 2000.

The latest working version on Windows 2000 is 1.8.0.

The disk is of about 100MB and the cache for the browser just 70MB. For whatever reason, it can't write above certain size (about 20MB) and the browser starts creating cache.trash folders :-?

If it works, don't touch it, "they say", I was happy with 1.7.5, why I updated without need? ;P

Edited by draisp, 30 June 2014 - 12:57 AM.

[Olof Lagerkvist]

Thanks for your report. Could you please give a few more details, such as filesystem (NTFS, FAT32 etc), typical size and maximum size of cache files and if you have other information that could be of interest. I try to reproduce this problem on Windows 2000 by creating a few files on a 100 MB memory-backed virtual disk, but have not seen it so far.

[draisp]

Command line:
imdisk.exe -a -u 0 -t vm -f "[filepath]CacheRamDisk100.imd" -m z:

With read/write properties.

The file size of the file that holds the virtual disk is 104.861.696 bytes (4KB over 100MB to obtain a 100MB "real disk" (less reserved for file system)).

It is formated in NTFS with 4KB cluster size.

The cache for the browser is set to 71680KB (less than full size because Gecko browsers actually use more than specified, so to fit in the virtual disk; a quite hard to find out size, BTW, damn mozilla).

And other details, what I mentioned. It can pass about 20MB in size. Then, the cache "retreats" to 14.4MB and creates cache.trash folders as if the cache was corrupted.

Also, you can't check the cache files (about:cache?device=disk) as it is empty. In other words, as it couldn't fill the cache, or read it, or write it. I don't know.

I switched back to 1.8.0, just to find in what version between 1.7.5 and 1.8.2 was introduced this problem and with 1.8.0 looks that was the last not causing this problem. So something in 1.8.2 could may be introduced.

Edited by draisp, 30 June 2014 - 02:45 PM.

[rottyk]

Warning! Version 1.8.2 blocked my thunderbird from writing new emails to disk. Got this message "Unable to write the email to the mailbox. Make sure the file system allows you write privileges, and you have enough disk space to copy the mailbox." Described here: http://kb.mozillazin..._to_the_mailbox or here: http://forums.mozill...=24110&start=30

Reverting back to 1.8.0 solved problem. Must be something wrong with the driver.

[Olof Lagerkvist]

Thanks for your report. I think I need to install some Mozilla based browser then and try to investigate what it is trying to do that fails for some reason. It should be possible to find out somehow!

[v77]

I also confirm. Since some days, my Firefox was unable to register the links on which I clicked. I was thinking of a corrupted profile and was about to rebuild one.
I just revert back to 1.8.0 and the issue is gone.
It's like Firefox is unable to write its "places.sqlite" (and likely some other files) when this file is located on an ImDisk volume. This file is the one where history and some other stuff are written.

Anyhow, this is an important issue, and I restored the previous version of ImDisk Toolkit as the default until this issue is fixed.

 

 

Edit: the file system of my ImDisk volume is NTFS with 64KB clusters, on Windows 8.1.

Edited by v77, 04 July 2014 - 12:00 PM.

[v77]

I just tested the version 1.8.3 and it now works perfectly. Thanks!

[Olof Lagerkvist]

Thanks for your report. Sounds great!

[draisp]

Looks like the cache is also working with the new 1.8.3 after a couple of hours of flush, fill, read, check and again

Edited by draisp, 05 July 2014 - 05:58 PM.

[rottyk]

Thanks, 1.8.3 is also working fine for me.

[Olof Lagerkvist]

This looks great. Thank you all for all testing and useful feedback!

[steve6375]

The 13 April 2014 version of imdiskinst.exe does not need a restart after install - SHA-1: 5f52fd473bdd54833b4fcce774e7356752fdc3fe

The latest version does (Win 8.1 64-bit) which is a nuisance...?

[Olof Lagerkvist]

The 13 April 2014 version of imdiskinst.exe does not need a restart after install - SHA-1: 5f52fd473bdd54833b4fcce774e7356752fdc3fe
The latest version does (Win 8.1 64-bit) which is a nuisance...?

There is no difference, really. The problem has to do with upgrades, in which case imdsksvc.exe cannot be replaced without a reboot anymore. It has been like that since Windows 7 if I recall correctly. The install/uninstall scripts stops this service before upgrade/uninstall, but the service process keeps running for a minute or so after the service has been reported as stopped. During that time, the file is locked and cannot be removed or replaced.

 

I have had a few ideas about how to solve this. One way could be to let the scripts call "taskkill" to forcefully kill the imdsksvc.exe process. Another could be to rename imdsksvc.exe. I will do some testing and see what turns out to be best solution!