RAM FS lifetime statistics

Can you explain the meaning of the two numbers displayed in the About window in RAM FS? And after what actions do these numbers change?

For example:
Processed 37.1 MB of data
Saved your storage from 35 MB of additional wear

Both numbers are lifetime totals for all your RAM FS volumes, accumulated since installation. They survive dismounts and reboots, so they only ever go up.

Processed X MB of data - all file data that has passed through RAM FS volumes: reads and writes.

Saved your storage from Y MB of additional wear - only the writes. Without RAM FS, storing those files on a physical drive would mean those bytes would have been written to your SSD or hard disk. That's the figure that matters for SSD endurance, which is why it's shown separately.

So in your example: 35 MB written, about 2.1 MB read.

These numbers change whenever an application actually reads or writes file data on a RAM FS volume, for example copying files, a build writing output, a cache folder placed there. Creating, renaming or deleting files moves no data and so it isn't counted.

Should these numbers increase when unmounting a RAM SF volume that is in use by another process?

No, unmounting itself shouldn't add anything. The numbers should climb only when a process reads or writes files on a RAM FS volume - that's all they measure.

Unmounting shouldn't subtract anything either: when a volume goes away, its data is gone, but the totals already counted should stay where they are, since they're a lifetime record of I/O rather than a picture of what's currently mounted.

Then it is probably a bug. To reproduce:
1. Mount a RAM FS volume.
2. Copy 1 MB to the volume.
3. Both numbers of Lifetime Statistics will increase by 1 MB.
4. Make the volume in use by another process and try unmounting it.
5. You'll get a message saying the volume is in use.
6. Open the About window and see that both numbers of Lifetime Statistics have increased by 1 MB again.

You're right, and thank you - that's a genuine bug, which we've now reproduced and identified here.

The counters are updated by a background task that periodically adds up the traffic of the mounted volumes. While a dismount was being attempted, the volume briefly dropped out of that sum, and when the attempt was refused and the volume came back, its traffic was added a second time. So you were seeing inflated figures. We also discovered that it wasn't just failed dismounts - saving a volume to an image file could have the same effect.

Good news: no data or volume behaviour is affected. It's purely a reporting error in those two numbers. A fix is being prepared for the next build.

This only applies to non-persistent RAM FS volumes. RAM FS volumes that periodically save data or when unmount use SSD resources to save data back to SSD disk. Therefore, it would be nice to see a third number indicating total amount of data saved during all unmounting or periodic saves.

It could be an interesting metric, noted for a future update.

On a related note, RAM FS was designed from the start to minimise SSD writes, both for disk longevity and performance. Periodic and shutdown saving to an image file only writes the changed data in 2 MB blocks, rather than rewriting the whole image. Folder mirroring works the same way: only changed blocks within a file are written back, not entire files, and blocks that were rewritten with identical content are detected and skipped as well. Unchanged files cost no disk I/O at all.

So while we don't currently show it, the amount RAM FS actually writes to disk is typically a small fraction of the data that passes through the volume - which is exactly what a third counter would demonstrate.

I know that periodic and shutdown saving to an image file only writes changed data rather than rewriting the whole image. Exactly for this reason such third counter would be very interesting.

And one more request: in addition to Lifetime Statistics, I'd like to see statistics (the amount of data written to the RAM FS and back to the SSD) for the previous session, from the previous PC boot to the current one.

I installed RAM FS v26.8.1 to test it. For the test, I copied some large files (100GB) and I also ran a test with CrystalDiskMark8 (1GB and 8GB ALL tests ). I am still using RAM Disk for the Temp files, not RAM FS.

In the About window, it shows:
Processed 14.8 TB of data
Saved your storage from 6.9 TB of additional wear

TB! Is that possible?
Can I reset these numbers?

Those numbers are real, and TB is exactly what CrystalDiskMark produces on a RAM FS volume. It doesn't just write the test file once and then stop. Instead, it hammers the volume for the full measurement time of every single test, so the real extend of test data has very little to do with whether you picked 1 GB or 8 GB.

We measured it here, using the same DiskSpd engine CrystalDiskMark drives, 5 seconds per pattern on a 1 GiB test file:

• SEQ1M Q8T1: 237 GB read, 304 GB written
• SEQ1M Q1T1: 94 GB read, 199 GB written
• RND4K Q32T16: 57 GB read, 61 GB written
• RND4K Q1T1: 22 GB read, 18 GB written

That is about 1 TB for a single pass of the whole set.

We ran the same eight patterns again with an 8 GB file and got 999 GB, within one percent of the 1 GB figure: the test size decides how much of the file gets touched, not how much data moves.

CrystalDiskMark runs five passes by default, so one ALL run moves roughly 5 TB either way. You ran it twice. Add your 100 GB of file copying and 14.8 TB processed with 6.9 TB written lands right where it should. The proportions match as well: a little under half of the total being writes is what you get from a benchmark that reads and writes in roughly equal measure.

So nothing is wrong, and this isn't the counting bug discussed earlier in this thread. That one only fires on a refused dismount or an image save, so unless you did one of those, none of it is inflation.

The wear figure is honest too. Those writes would have gone to your SSD had the volume been a real drive, which is the awkward thing about benchmarking an SSD: the test itself spends the endurance you are measuring.

As for resetting them, there's no way to do that in the current build. The totals are held by the driver and nothing in the interface clears them, so we'll add a reset button to the About window in the next update.

I gave the new reset button a try (v26.09). Unfortunately, it didn't work for me:

Quote

Error message: not supported by driver (Error 1)

Thank you for reporting the error. We recently moved to a new installer builder, which changed how a 32-bit installer finds the Windows system folder from script code. This led to the new interface talking to the old driver, which knows nothing about the new reset command. Hence Error 1.

It is now rebuilt as a 64-bit installer, so fresh downloads are unaffected. In you case, you don't need to reinstall anything. Simply restart your Windows - and the button should work. If it still complains, one more restart will fix it.

I restarted Windows and the button now works as expected. Thank you very much, Andrew.

I feel like I'm crashing a party here, but how can I turn off this feature in both RAM Disk and RAM File System?
I checked to see if there is a registry key that controls it, but I didn't find anything.

There's no switch for it in either product, which is why you couldn't find a registry key. The counting is built into the driver.

It costs practically nothing though. Each read or write bumps a couple of counters in a per-CPU slot, with no locks and no atomic operations, so it doesn't even register against the memory copy it's counting. A background thread adds those slots up once a second and saves the totals to the registry once a minute. That's the entire cost, and it's the same design in both RAM Disk and RAM File System.

Nothing leaves your machine either. The numbers sit in the driver's own service key locally and are only read back when you open the About window.

So there's nothing to gain by switching it off. If it's the numbers themselves you'd rather not look at, RAM File System 26.09 now has a Reset Statistics button in the About window.

It's not so much about what is to gain. I like to have more control in general, like some people.

Nowadays devices and software are built with functionality that is on by default. The user then needs to manually disable it if they choose. However, they are still given the choice which is the more advisable option.

About a decade ago I bought a device to test a specific task. The device had Bluetooth functionality that couldn't be switched off. A simple firmware update would have allowed users to manually disable Bluetooth (as confirmed by the manufacturer itself).
I then requested the manufacturer to upgrade their firmware for the device in question, and to include this functionality. The manufacturer didn't satisfy a simple customer request. Might have had a valid reason, I can understand. However I asked for a refund on the 27th day after purchase (of 30 allowed), and never again bought anything from that manufacturer.

Sounds like I'm trying to send a message... to the contrary. Your tool is unlike any other on the market (currently).

I develop software along with a small team. We carefully listen and try to accommodate requests from customers (even the wildest ones). More customization is a positive for everyone with a bit of extra headache for us developers.

That's a fair way to think about it, and it isn't an unreasonable thing to ask for in principle. Let me explain where we draw the line, because it isn't arbitrary.

We're deliberately sparing with switches. An option is permanent once it exists: it has to be honoured in the driver, kept working across every Windows build, documented, tested and supported for years. A few dozen individually reasonable ones and you have a product that is mostly settings, which is a worse product for everybody, including the people who asked for them. So the test we apply is whether an option changes what the software actually does to your machine: what gets written to disk, drive letters, whether memory is wiped, anything with an effect outside our own driver.

The statistics don't clear that bar. They aren't a feature doing something to your system, they're a couple of counters being incremented in the driver's own memory. No disk I/O, no network, no effect on the volume or its contents, nothing that leaves your machine, and the cost is too small to measure against the memory copy it's counting. Turning them off would change nothing you could observe, apart from the two numbers in the About window.

Your Bluetooth example is a good one for the opposite reason. A radio is a real behaviour: it transmits, it can be reached from outside, it drains the battery, so being unable to switch it off is a legitimate complaint. We'd have been on your side there.

The one thing that genuinely was missing here was a way to clear the numbers, and that's in RAM File System 26.09 now, as Reset Statistics in the About window. RAM Disk doesn't have one yet.

For what it's worth, this thread is a reasonable illustration that feedback does get acted on: it turned up a real counting bug, which was fixed, and the reset button, which didn't exist a month ago. Not every request becomes a setting, but every one gets read and thought about.

We don't see eye to eye and that is perfectly fine. However, some users have a concern for privacy, and will always put that first. In 2026 it is baffling how (worldwide) people just do not care. This goes for regular folks, but of course starting with big corporations and small businesses and how we choose to write software. Writing software with privacy in mind is a choice, not an accident. I write software myself, but collectively everyone's at fault for letting things get out of hand. Not enough people complained when there was a need for it. For instance the reason you can still enjoy some of your privacy is because others actively fight for it, and continue to do...

Privacy first is however becoming a market in itself. Kind of like over a decade ago organic or non-GMO labeling for food began to take off, defining a market for a never before existed demographic. It is now a market worth USD 170 billion and growing. You could slap a "privacy guaranteed" badge on your tool and you'll be sure to attract a specific demographic in addition to your regular one.

The Bluetooth example was first a privacy concern (for my business) and then a radio frequency second (for health reasons). Every time the device is powered on it is yelling out loud (to anyone listening): I AM HERE! This can be a serious problem if one is trying to conduct specific testing in a confidential manner. The average user may only be at risk if targeted by stalkers or thieves.

Anyone who doesn't buy organic food will think those buying it are wasting money, and those that do will think the other group is eating "more" harmful pesticides.

SSDs save the amount of data written to it anyway. This information can be read by all kinds of tools and is exposed to anyone who can gain access to the drive. The point however is the one I made above. Those who care will agree and those who don't never will.

My request is one that had previously been made by other people. I just added myself to the queue. This is how you'd know that users and customers express an interest in a particular feature. From what I read around in the forum you and your colleagues seem to be aware of this.

Like I said previously, this tool is one unlike many others of its kind. I particularly praise that.

I'm not interested in arm wrestling this (not that I stand a chance), in fact your explanation is understandable, thank you for providing it. Nonetheless, hats off to your team if they decide to go the QA testing trouble of implementing a seemingly cosmetic change.

I am a huge fan of disabling useless features, and a huge defender of privacy. Yet in this thread I feel completely satisfied with the clear and detailed explanations by the developers.
The statistics data
- doesn't get sent anywhere (respect for user privacy),
- doesn't affect SSD I/O (respect for hardware).
Therefore, it is a purely cosmetic thing, and as such it is simply a matter of not looking at it if someone happens not to like it. So I am with the above commenter on one point: RAM FS and RAM DISK are outstanding tools!

Thank you Andrew for the comprehensive explanations. I personally found those numbers informative, so I was glad to learn that they do not produce any true side effects.