RAM drive TRIM?

[clarkn0va]

I'm using OSFMount (great program) to create RAM drives on my computer running Windows 8.1. When I first create a drive, the task manager show no increase is memory used. When I copy files to the RAM drive, the reported memory usage goes up as expected.

However when I delete files from the RAM drive or format it, the reported memory usage does not go back down. I don't know if this memory will be automatically freed up if it is needed, but even if it is, won't the fact that this memory is currently seen as "In use" potentially lead to memory fragmentation?

And if for no other reason, I'd like to see how much free memory I actually have when looking at the task manager. The fact the the "System" process is my biggest user of memory right now at several GB is somewhat ambiguous.

So does anybody have any thoughts on this? If it were possible to turn on TRIM for a RAM drive, would this change the way Windows reports RAM usage? If so, can this be done? Or can I trick Windows into thinking the RAM drive is an SSD to coax it to turn TRIM on?

Thanks.

 

[imagoon]

It would have more to do with OSFMount than Windows. Even if you could force TRIM on, OSFMount needs to honor the request. I would contact OSFMount Devs about the issue.

 

[Micrornd]

Windows is doing what it should.
Once you create a ramdrive, that memory is dedicated to the ramdrive as a storage medium and no longer available to Windows as memory, that is why you see no increase/decrease in used memory.

Deleting files or formatting the ramdrive makes no difference in memory usage, since the ramdrive still exists and that memory is still no longer available to Windows.

The only way to get that memory back is to actually delete the ramdrive itself.

Memory fragmentation is a non-issue in a modern OS.

TRIM makes no difference since ramdrives operate on the FIFO principle, which is also their greatest limiting factor.

 

[Cerb]

Memory fragmentation is a non-issue in a modern OS.

Nominally true, but there are caveats:

1. You need a 64-bit OS. 2-4GB in 32-bit does lead to fragmentation problems, which usually present themselves as perceptible stuttering and jerkiness. Both Linux and Windows normally do background compacting, but both will go into an, "oh, shit," foreground compacting spree, if RAM is technically available, but not allocatable. With the 2GB/2GB (or 3GB/1GB) limits, the above can occur even without filling up all your RAM--the OS or application simply need to have too many sparsely filled pages, which is pretty easy on x86. In a 64-bit OS, current Windows kernels would need multiple TBs of RAM to run into the same kind of issue.

2. You need to have spare RAM, or the same thing as above will happen, even in 64-bit. All that RAM going to file caches is not being wasted, and MS has tweaked their caching to be fairly efficient at being re-used (as of Vista, FI, they were using 256KB contiguous chunks, whenever possible; the exact value was historical, but by by doing that, they can quickly zero and re-purpose all that RAM quickly, and get forced to background compact fairly aggressively, to keep such chunks available for caching, so you don't get hindered by it).

Since RAM is typically sparsely allocated initially (for various good reasons, but they would bloat this post up even more), and often de-allocated randomly (in the sense of being entirely unpredictable, thus leaving gaps that are unusable, without defragmenting it), RAM fragmentation occurs. But, with enough spare RAM on a 64-bit OS, the OS' background memory management almost always outpaces the needs of applications.

The above are why using all that available (usually caching) RAM as a RAM drive is counter-productive, and you typically really want either much more RAM than you could otherwise make use of, including having 50-100% more for caching, for a RAM drive, or just deal with 200+us access times of an SSD, and get much more drive space for the money, to boot.

In general, though, just unmount it to free up space. I'm pretty sure DataRAM's will shrink in place (you can try, with the free version), but it is a pay program for >4GB. Even if it could fake an SSD supporting TRIM, that would not shrink the size, just make it an interesting diagnostic tool.

 

[Micrornd]

I definitely agree.
I guess I should have said "64bit" rather than "modern".
Could be worse, though, he could be using it for the paging file

 

[John Connor]

Hey, on a laptop with a single SSD puting the page file and temp file in a RAM drive is not only secure, but limits wear and tear.

 

[Cerb]

Hey, on a laptop with a single SSD puting the page file and temp file in a RAM drive is not only secure, but limits wear and tear.

If you have enough RAM that you don't need a page file to run your programs without crashing, and you are sure of this, and/or willing to keep track of it, disabling the PF will reduce your SSD's wear and tear, and leave you with all the free RAM that you had when the PF was on the SSD.

Putting your PF in a RAM drive will cause Windows to do more work, and to act like it has less RAM.

Now on a laptop, which runs risk of being stolen, I'll grant you security for the temp files. Though, if you're that worried, you should probably have your profile encrypted.

 

[John Connor]

Well, I thought about it and I guess it doesn't make sense to put the page file in RAM, but the temp files a must. I set my page file to 1024 MB for the initial and maximium size to reduce fragmentation. Although, on a SSD it doesn't matter but it was something I read about doing to a SSD.

I wanna build a PC with at least 32 GB of RAM and load all my games into RAM. These would be separate profiles where you load and unload.

 

[Micrornd]

You want to remember that using a ramdisk for temp files is normally counter-productive.
Those same temp files would be manipulated in your regular ram normally (which you have now decreased in size to make a ramdisk).

Sending the temp files to a ramdrive doesn't manipulate them faster, since they still go through regular ram to get there, but can actually be slower because ramdrives are FIFO.
So if the temp file and it's manipulations exceed the size of the ramdrive, they must be paged out and then brought back to the ramdrive while being manipulated.

And if you are thinking about using the ramdrive as a browser cache, remember that browser temp files are held in temp until they are completely downloaded, so if the size of the file exceeds the size of the ramdisk, because a ramdisk is FIFO and browser temp files are not paged, the file will never completely download.
How the browser handles this can range from a simple warning, to a freeze or crash.

Ramdrives had a place when HDDs were slow, SSDs didn't exist, ram was expensive, CPUs were slow, and OS's were lousy at managing memory, but that time has come and gone.

Now, all they do is steal memory away from the operating system and essentially slow it down, except in highly specialized cases.
Those that are still pushing ramdrives for general use either have a product to sell or are lingering in the past (that's probably the least offensive way of saying it :whiste

If a blink of the eye makes a difference to you, hop back in your time machine and go home

 

[John Connor]

Well, I have Firefox's cache in memory and the temp files go into a 200 MB RAM drive on the laptop and I have downloaded some rather large files with no problem. The file is placed in your downloads folder as a temp. I've seen it, there are two files. Like Terminator 1 part.mpg and Terminator 1.mpg

 

[Dufus]

When I first create a drive, the task manager show no increase is memory used.

Check how much the commit value goes up, not "how much RAM is in use" but it depends on how the RAM Drive software was written. For instance some will use the re-mapped RAM on 32-bit systems with 4GB RAM installed that Windows ignores and is maybe the only time having the pagefile on a RAM Drive makes sense. There shouldn't be any need to worry about fragmentation really.


While it might be possible to utilize trim I think it might be counterproductive as the RAM Drive is likely to want to keep all of it's assigned memory to itself, release it and there is no guarantee it will be given back!

And if for no other reason, I'd like to see how much free memory I actually have when looking at the task manager.

I did link a small program for demonstration but on second thoughts maybe best just to run it myself and post the result. Later.

 

[Lorne]

OP, Are you thinking that Trim will make the ramdrive work dynamically?, Not going to work, Sadly no one has ever gotten a good working dynamic ramdrive to work on the PC, Sadly the Amiga took it to its grave.

There is absolutely no reason to use Trim on a ramdrive what so ever, There is no garbage to be collected in on board memory compared to non volatile memory in a SSD.

 

[Cerb]

OP, Are you thinking that Trim will make the ramdrive work dynamically?, Not going to work, Sadly no one has ever gotten a good working dynamic ramdrive to work on the PC, Sadly the Amiga took it to its grave.

tmpfs and ramfs are sized based on their contents. They're stuck outside of Windows, though, just as much as anything Amiga might be.


If Amiga had such a thing...I wonder if AROS does?

 

[Dufus]

Here's the example of reserving lots of memory without using it. RAM installed is 4GB.

If you're only looking at "Memory usage" / "In use" / "Available", then you're not seeing the fuller picture, committed is very important too. Check this when allocating your RAM Drive. If the software is using the Windows Memory Manager then I would expect your commit size to increase with the size on the disk.

 

[Ichinisan]

Hey, on a laptop with a single SSD puting the page file and temp file in a RAM drive is not only secure, but limits wear and tear.

LOL! <-- I laughed at this.

This suggestion is completely pointless. The page file is where stuff goes when you don't have enough memory for all your processes. With a normal HDD, the system grinds when it's swapping to the page file while loading more data into RAM because mechanical storage (HDD) is thousands of times slower than electrical storage (RAM). SSDs are fast, but still nowhere near as fast as RAM...which has a much more direct pathway to the CPU.

Allocating memory as a RAM drive to contain a page file defeats the purpose of a page file. It also reduces the available RAM so your system is more likely to waste time and resources paging data to-and-from it. Think about it: Why would you want to move data from-system-memory-to-system-memory?

Just turn-off the page file! Anything else is wasting RAM.

 

[Ichinisan]

The RAM drive only allocates memory as data is written to "clusters" on the virtual drive. You partition the RAM drive and create a filesystem, but only a handful of data clusters are actually modified, so only a handful will have RAM allocated.

When you copy files to it, more data clusters within the partition have been modified, so more memory is reserved as the data values are written.

When you delete the file, you've basically deleted its entry in the filesystem's table of contents, so those sectors are marked as "free" within the filesystem. However, the RAM drive software doesn't know anything about which-ever file system you are using. It just sees that data clusters have had values written to them.

Even if the clusters were written-over with zeroes, the clusters were still flagged as "modified" and their values are still stored. As far as the virtual drive is concerned, some software wrote zeroes to those clusters and expects to read zeroes back from them.

There you go.

 

[VirtualLarry]

The RAM drive only allocates memory as data is written to "clusters" on the virtual drive. You partition the RAM drive and create a filesystem, but only a handful of data clusters are actually modified, so only a handful will have RAM allocated.

When you copy files to it, more data clusters within the partition have been modified, so more memory is reserved as the data values are written.

When you delete the file, you've basically deleted its entry in the filesystem's table of contents, so those sectors are marked as "free" within the filesystem. However, the RAM drive software doesn't know anything about which-ever file system you are using. It just sees that data clusters have had values written to them.

Even if the clusters were written-over with zeroes, the clusters were still flagged as "modified" and their values are still stored. As far as the virtual drive is concerned, some software wrote zeroes to those clusters and expects to read zeroes back from them.

There you go.

Unless the RAM drive supported TRIM, then it could return blocks that are no longer in use back to the OS.

 

[teiva]

OP, Are you thinking that Trim will make the ramdrive work dynamically?, Not going to work, Sadly no one has ever gotten a good working dynamic ramdrive to work on the PC, Sadly the Amiga took it to its grave.

There is absolutely no reason to use Trim on a ramdrive what so ever, There is no garbage to be collected in on board memory compared to non volatile memory in a SSD.

The rrd on the Amiga worked very well and even survived reboots. I haven't seen anything similar on pcs just yet.

 

[Cerb]

The rrd on the Amiga worked very well and even survived reboots. I haven't seen anything similar on pcs just yet.

You haven't looked very hard. A PC not running Windows is still a PC. Surviving reboots generally takes a script or two, though.

 

[taq8ojh]

Hey, on a laptop with a single SSD puting the page file and temp file in a RAM drive is not only secure, but limits wear and tear.

I just had to.

 

[John Connor]

Obviously you didn't read my second post, Jerk.

 

[taq8ojh]

Oh you mean this one?

Well, I thought about it and I guess it doesn't make sense to put the page file in RAM, but the temp files a must. I set my page file to 1024 MB for the initial and maximium size to reduce fragmentation. Although, on a SSD it doesn't matter but it was something I read about doing to a SSD.

I wanna build a PC with at least 32 GB of RAM and load all my games into RAM. These would be separate profiles where you load and unload.

I apologize.

 

[Ichinisan]

Well, I thought about it and I guess it doesn't make sense to put the page file in RAM, but the temp files a must. I set my page file to 1024 MB for the initial and maximium size to reduce fragmentation. Although, on a SSD it doesn't matter but it was something I read about doing to a SSD.

I wanna build a PC with at least 32 GB of RAM and load all my games into RAM. These would be separate profiles where you load and unload.

If you're interested, I just read an article from the authority on the matter:

Should the pagefile be placed on SSDs?

Yes. Most pagefile operations are small random reads or larger sequential writes, both of which are types of operations that SSDs handle well.

In looking at telemetry data from thousands of traces and focusing on pagefile reads and writes, we find that

Pagefile.sys reads outnumber pagefile.sys writes by about 40 to 1,
Pagefile.sys read sizes are typically quite small, with 67% less than or equal to 4 KB, and 88% less than 16 KB.
Pagefile.sys writes are relatively large, with 62% greater than or equal to 128 KB and 45% being exactly 1 MB in size.​

In fact, given typical pagefile reference patterns and the favorable performance characteristics SSDs have on those patterns, there are few files better than the pagefile to place on an SSD.

http://blogs.msdn.com/b/e7/archive/2009/05/05/support-and-q-a-for-solid-state-drives-and.aspx

 

[John Connor]

For the record my page file is 1024MB min/max and not in RAM!

 

[Ichinisan]

For the record my page file is 1024MB min/max and not in RAM!

If you do something that causes all your processes to occupy more memory than your total system memory, you really don't know if the excess is going to be less-than-or-equal-to 1GB. Disable the page file or leave it with dynamic size.