20161120: new cleanup function for dynamic ramdisks
Status: Inactive
Brought to you by:
w77
Menu
▾
▴
This version brings a new cleanup function for those who cannot use the TRIM commands with the dynamic ramdisks.
Instead of gradually filling the whole space with an empty file, a small empty file is now created and then moved on the free space with the FSCTL_MOVE_FILE control code.
With this command, the file system first checks that the destination does not contain used clusters, this is why it can be used reliably on a volume in use.
This command is less efficient than directly writing a file (especially with the FAT file systems), but as it is used only where memory blocks can be freed, in practice the final result should be faster in most cases. Consequently, the time required is now relative to the amount of RAM to free instead of the size of the empty space.
An advantage of this method is to avoid filling the empty space, which can be especially useful with softwares that monitor the size of the empty space.
This also means that the "Security Margin" parameter is no longer required. Therefore I removed everything related to it.
This version should also process all the requests slightly faster.
Is there is any command to clean up manually?
No sorry, but this could be something to add. Why do you need that?
sometimes it doesn't clean automatically, because there is still files writing to the disk, even when I delete files from the RAM-disk. So a manual clean up could be very useful.
Thanks for the reply
Merry christmas and happy new year from Sweden :)
Did you try to increase the "Maximal Activity before Cleanup" parameter? (RamDisk Configuration Tool -> Advanced -> Dynamic Ramdisk Parameters)
This may be enough to fix your issue.
Let me be more specific.
When deleting or moving files from the ram-disk while data is still written, sometimes, regardless of the "Maximal Activity before Cleanup", it wont clean up. And when finishing writing the data to the RAM-disk, it will clean up everything except the data that weren't cleaned up.
Example:
RAM-disk 16GB
Data to be deleted: 2gb
Data is still written: 2gb
Usage (4gb) free space /12gb , private byte allocated to RamDyn.exe is 4gb.
When deleting the 2-gb data:
Data is still written: 2gb
Usage (2gb) free space /12gb , private byte allocated to RamDyn.exe is 4gb.
When finishing the auto clean up will only clean up.
Usage (0 gb ZERO) free space /14gb , private byte allocated to RamDyn.exe is 2gb.
Here a manual clean up will be useful :)
Last edit: paradis pal 2019-01-01
This can occur if a file is deleted when the cleanup function is processing.
In this case, the cleanup function will be triggered only if a larger file is deleted.
Yes, this can be an issue when files are big.
I come back quickly on this issue.
With all respect, I think I missed saying that it is about writting so many files att the same time.
Sometime there will be about 80 files whitch are written simultaneously, the data is written not more than 1mb/s ( it is rendering).
Last edit: paradis pal 2019-01-01
The whole system is not optimized for processing several files at the same time on a single volume. But still, such a speed is a bit surprising...
About the previous issue, I will first try to explain what happens.
When the cleanup function is processing, we cannot know what occurs at the same time. Files can be deleted, but also files filled with 0 can be written (which reduces the number of allocated memory blocks), or several files can be written and fragmented (which increases the number of allocated blocks beyond the minimum necessary to store the data).
So, in short, everything is possible and we known nothing about the situation when the cleanup ends.
Therefore, I calculate the difference the memory actually allocated, and the used space in the volume. And then, I see how this difference evolves to trigger the cleanup the next time.
For the solution, I see 2 possibilities:
1) Add a parameter to avoid the case of a big file deleted while the cleanup. It would force the cleanup if a large difference is seen between the allocated memory and the data size. There is a risk though: if this difference is due to something else, the cleanup will be triggered endlessly.
2) Add a manual trigger. But there are various difficulties to implement that.
Of course, I could also do both. :)
By the way, how do you see the manual trigger? Something in command line? A button in a GUI?
I sincerely apologize for the late reply, just got held up.
A manual trigger is perfect for me. just a command line if it is easier for you. Cause every time I check the used space of the ramdisk and used ram by RamDyn.exe I see always a difference.
Now I am on 50GB ramdisk, and the differences varies from 100mb to sometimes 2gb.
I think I have to admit the limits of the current method...
Therefore, I started to see how to add a command line to trigger the cleanup.
It should work without administrative privileges.
Thanks in advance. Wish you a good and happy year :)
I have noticed this weird behaviour, and I found out it is due to disk fragmentation, using defrag will fix this issue
The version 20190130 adds a command to manually trigger the cleanup function.
As said in the syntax help, using 0 as the size triggers the function. So, for instance:
RamDyn.exe R: 0
This command does not require administrative privileges.
Tested and it works! You are the man! I can't really express how thankful I am.
Have a nice day :)
Thanks for that, it helps cleaning the memory, yet you need to defrag the RAM-DISK
Thanks for that, it helps cleaning the memory, yet you need to defrag the RAM-DISK
Does not seem to work when you use a mountpoint like C:\RamDisk or how should I specify it then ? I'm doing RanDyn.exe C:\RamDisk:0 -> Launches the help dialog, nothing else seems to happen ?
The command should be :
RamDyn.exe C:\RamDisk 0
But it seems there is a major bug with RamDyn and mount points. Symptoms changes depending on the OS : freeze of Explorer, the cleanup command that works or not, unable to unmount the ramdisk...
It seems the previous version is also affected.
Last edit: v77 2019-02-03
Sad to hear, but really good to know ! Thanx. Switching back to previous version. (Was using it in test lab only anyway)
The more tests I do, the less I understand what's happen.
All versions are affected since the big change of the cleanup function (version 20161120).
The bug occurs when the cleanup function works on a volume mounted on a folder.
Sometimes it works... very slowly. But RamDyn uses almost no CPU time. It's the file system that merely waits at each request for moving the small empty file (FSCTL_MOVE_FILE).
This is definitely a bug of the file system (and not the first one I find). I am not sure there is a workaround.
If you use a mount point and everything works well, it means that you likely don't use the cleanup function, but rather TRIM. Or something else prevents the bug to occur.
I did my tests on Windows 7 and Windows 10, and the results are the same.
Could it be a workaround (until it could be fixed) to use a normal RamDisk with a letter (for example X) and use a (Junction?) Link (with for example the Link Shell Extension Tool) at "C:\RamDisk" to "X"? It should work that way like a mounted volume on a folder but without this bug, but I didn't have test it yet and I'm not sure if I missed something.
Last edit: Hoto 2019-02-05
It is even possible to temporarily define a drive letter to the ramdisk... This is done to format the ramdisk when it is defined on a folder.
But this would still be a bad solution, because users who want a ramdisk only in a folder do not want a drive letter.
I will consider that only if there really is no other possibility.