#Significant read/write activity to C: SSD while playing

1 messages · Page 1 of 1 (latest)

mental ocean
#

There is a thread in the Steam Forums about this so I did some testing and compared the output to similar games (Valheim and Enshrouded).

The results are clear that simply being in a world causes Windrose to constantly and aggressively write to your C: drive. I assume this is save file related since they are in %appdata%.

For a 60-90 second session in similar size bases, here's what I saw in task manager:

Windrose (~10MB Save File)
I/O Read: 32,638,339,754 (~32GB)
I/O Write: 1,305,479,753 (~1.3GB)
I/O Other: 28,344,187 (~28MB)
Constant SSD usage

Enshrouded (~1.2MB Save File)
I/O Read: 7,738,973,403 (~7GB)
I/O Write: 695,285,313 (~695MB)
I/O Other: 2,549,397 (~2.5MB)
Very little SSD usage

Valheim (~50MB Save File)
I/O Read: 1,188,320,759 (~1GB)
I/O Write: 5,075,385 (~5MB)
I/O Other: 874,331 (~875KB)
Very little SSD usage

I posted this thread on X if you want more info (and tagged @playwindrose).

https://x.com/PixelOperative/status/2046990002219888822

Screenshot_2026-04-22_120209.png
Pixel Operative (@PixelOperative)

A post on the Steam forums for Windrose caught my eye. There is concern is that Windrose is writing to player's C: drives far too aggressively as it saves the game state when you play.

The concern is that this type of constant write behavior isn't good for SSDs.

🧵Below

X ·
lunar cedar
#

thank you passed to the tech team

mental ocean
#

Thanks!

mental ocean
#

FYI I tested on a dedicated server as well and the server sees the same significant read/write to the save game drive as expected.

However, the connected client SSD read/write is still pretty high. I suspect the local client are still constantly reading/writing to \Players and/or \Accounts on the local machine.

mental ocean
potent storm
#

A friend and myself wanted to buy the game. Just saw the post on steam and your video. We will gonna wait till a hotfix is out. Thanks for your work 🙂

mental ocean
#

I'd say certainly grab it after they fix this if you are concerned about this issue but still interested in the game. It really is an amazing game even in the first week of early access. 👍

rose helm
potent storm
grand wadi
potent storm
vapid plank
#

Hope this be fixed soon. Windrose is a really fun and addictive game.

molten socket
rose helm
tall ridge
#

@rose helm most people dont know anything about computers, they just wanna have fun playing video games after work. Ofc problems like this will bother and stress people worried about their computers. Why shouldnt it be allowed to talk about. It is a good way to improve the game. Thanks to the guy who made those tests

rose helm
obtuse cave
#

OK, so for us technical noobs:

Should we be worried or not?
because all you say is Abacadabra for me hehe.

rose helm
#

Should we be worried or not?
Not in the slightest.

obtuse cave
#

Thanks 😄
I was almost stressing out....

tall ridge
#

@rose helm unplug your router it will be the first big step into a world you dream of where you decide people cant have a conversation on the internet

torn kelp
# rose helm > Should we be worried or not? Not in the slightest.

I'm sorry but that's not entirely true, Whilst not "dangerous" the amount of data being written to the drive over a short period of time is concerning enough that it needs to be looked into.

If the game is constantly causing upwards of 50GB of writes to a drive in an hour that level of writes is a potential issue for solid based storage due to the limited writes of the memory.

rose helm
#

This is not early days of SSDs under Windows XP era without TRIM and you'd have to write untold terabytes per day to make any significant wear on the SSD.

And in the age of free youtube videos and awesome guys doing artificial stress tests, how are people still not informed ?

tall ridge
#

@rose helm
Because there are countless people who spend all their time studying obesity medicine so they can perform fat removal surgery on you.

Many people spend most of their time figuring out hair transplants so you don't end up bald.

Not everyone is a mommy's breadwinner and can spend 24/7 reading Reddit and commenting on Discord.

Try to find the strength to forgive these uneducated, lost souls.

rose helm
tall ridge
#

By "you" i didnt mean you personally. Its just an expression. If you took it personally i am sorry

#

You on the other hand calling everyone uneducated... Something to think about.

white condor
torn kelp
# rose helm This is not early days of SSDs under Windows XP era without TRIM and you'd have ...

That is not really accurate.

Most decent modern SATA or NVMe SSD's are often rated somewhere around 500 to 600 TBW. If a game is writing 1 GB every minute, that works out to about 60 GB an hour. At 4 hours a day, that is roughly 240 GB a day.

At that rate, you are looking at roughly 6 years before you hit endurance levels of the drive, Now that's based purely on Windrose writing to the drive which isn't the case, and admittedly most people aren't playing for six years straight. So no, it is not going to kill a drive in a few weeks, but saying it is meaningless wear is not right either.

The bigger point is not that Windrose will instantly destroy an SSD, it is that if it really is writing far more than expected due to constant persistent saving, then that is still unnecessary wear and something worth investigating and fixing.

rose helm
#

The bigger point is not that Windrose will instantly destroy an SSD,
The saddest part is, that all the actual reports present it as such.

hence why I said the OP here should've made just a plain bug report.

torn kelp
tall ridge
torn kelp
# rose helm Never said the issue doesn't exist for some select people (it's not a global iss...

From what I can tell and what I've looked into with different save files, the issue gets worse with more of the map explored/larger games/bigger bases.

It almost looks like the game is saving the entire world state constantly vs just saving changes/updates to the local vacinity of the player.

I wouldn't say it's being reported as SSD destroying, at least I don't read OP's post that way, unfortunately peoples lack of understanding can fuel concern but at the same time I believe it's serious enough it should be hotfixed immediately (ie days not weeks) and it should be the priorty for the devs, That is my personal opinion however.

rose helm
#

I wouldn't say it's being reported as SSD destroying,
It is what it is, brother

image.png image.png image.png
torn kelp
#

The first image is sensationalist, sure but OP's post above isn't. The second one, Is more level headed and true, the level of writes the game seems to put on the drive isn't "good"

tall ridge
# rose helm > I wouldn't say it's being reported as SSD destroying, It is what it is, brothe...

I guess you are completely ignoring anyone who started arguing with you because your chatgpt 1.0-mini from early era of openai cant tell you how to argue with people who have more knowledge in this topic than you and your openai model.

Or you are just mad you were ignored by moderator who you desperately tried to call to ban whoever arguing with you for no reason.

I think everyone can see what kind of an expert you are typing all these. Good luck banning whole internet of fear mongering people. Ban them all. Ban them all

mental ocean
#

I'm going to see if I can close this post since the report has already been surfaced to the Windrose team for further investigation. At this point this post is just people arguing/insulting each other which isn't helpful regardless of whether this is an issue that matters or not.

torn kelp
#

So doing some testing, most of the usage seems to be relating to the RocksDB. this is conducting thousands (at points over 130,000 edits a second to the log file, the changes are small, into the 100 bytes per edit mark, but it adds up very quickly.

image.png
haughty hull
# torn kelp So doing some testing, most of the usage seems to be relating to the RocksDB. th...

I was looking into this in a similar manner to you and saw the same behaviour. I made a few comments on the steam thread, but the forum there isn't great at keeping conversation with people haha

I believe the LOG file is debug logging, and optional and distinct from the WAL logs which are more intrinsic to the db's functioning.
This link mentions the LOG files https://github.com/facebook/rocksdb/wiki/RocksDB-Overview#database-debug-logsaka-info-logs
I can't find documentation that actually specifies the WAL filepaths, but google AI is giving this (no idea where it sourced that from, the links it references don't mention this) and checking a rocksdb folder shows that a xxxxx.log file does exist - and 0B in size makes sense because I dont have the game running right now.

I'd have to profile the game again to check but I didn't notice heavy write activity to files of this format, only to the LOG file, so I think that it should be simple enough for the devs to disable the debug logging without interfering with the actual behaviour of the db and we might see a marked improvement from this alone

image.png image.png
#

Skimming through the rocksdb docs it appears there's also a range of ways to configure its behaviour, from rate limiting i/o to disabling WAL entirely. No doubt this comes with data reliability tradeoffs but it does look like optimising the db usage or giving users some settings to control it a bit shouldn't be too difficult

torn kelp
#

I did some more digging on this, and while a lot of the small repeated writes in my ProcMon screenshot are going to the LOG file, that is not where most of the write volume is going overall.

I ran a 40 minute PerfMon capture while out at sea, and over that window the process averaged about 23.8 GB/hour with peaks of nearly 50 GB/hour. Those writes were clearly not all just going to the RocksDB debug or info log.

So I think you are right that the LOG file itself looks separate from the actual WAL files, and disabling or reducing that logging may help a bit, but it does not look like that alone explains the full amount of disk write activity being measured. That is why I do not think this is simply a case of “turn off debug logging and the issue goes away”. There seems to be a wider write pattern going on than just the RocksDB LOG file being spammed.

content.png
haughty hull
#

I haven't run perfmon beyond a global disk profiling config yet, but at one point I was trying to keep an eye on what seemed to be topping the disk use in resmon and found C:\$LogFile getting a lot of it. My rough understanding is that windows uses this file to track metadata changes on other files, e.g. last modified timestamps. I could believe that the constant LOG writes and rotation from rocksdb is thus contributing to C:\$LogFile getting thrashed even harder, and thus indirectly having an outsized impact on the disk util

#

I dont know of a way to test this hypothesis without the game being modified though 😅

elder berry
native sapphire
#

This looks like another reason RocksDB is bad for making games with lol

torn kelp
#

RocksDB wasn't designed for games, It seems a novel use case but if memory serves it was designed originally for Facebook

#

The biggest drawback, and something RocksDB’s own documentation makes clear, is that because it is an LSM based storage engine it is naturally very write heavy by design. It writes to the memtable and the WAL at the same time, then later flushes to SST files and goes through compaction. That is just how the system works.

From an enterprise point of view, that level of write activity is usually less of a concern because the focus is on durability, throughput and handling large scale persistent workloads. But when you move that same approach into consumer software, especially a game running on a normal home SSD, the write volume becomes much more of a practical concern.

I am not saying RocksDB cannot be used in games, but it is not as simple as dropping it in and expecting it to behave like a typical save system. The way it works at its core means you need to be very careful about how often you persist data, how much you write, and how the whole persistence layer is designed around it.

But what do I know, I only work in the industry using LSM's daily

haughty hull
#

I think I saw the docs mention rocksdb was targeting flash memory as the storage medium at first, so I could see it being a better fit for mobile games

#

I think generally speaking it's a good fit for windrose too - especially when you consider the server hosted approach. Just needs some tuning

hollow hound
#

i tried now enshrouded and its 150KB/s which is 200 times less than 30MB/s O_O

#

i will be waiting for a fix since windrose > enshrouded for me personally

mental ocean
#

Thanks to everyone who's provided constructive and detailed investigations on this. Hopefully this helps point the dev team in the right direction for a quick mitigation.

torn kelp
# haughty hull I think I saw the docs mention rocksdb was targeting flash memory as the storage...

Rocksdb is an in memory and log file database system so the system will always have mentables in RAM ie flash memory as well as log files on your storage device. It was designed this way for durability so that if one side crashes or have an error the data isn't lost as it stored on the other side such as the MEM table or the log files.

LSMs like this could be very beneficial to open world server games such as this but we'll be very challenging due to the resources required.

signal abyss
# obtuse cave Thanks 😄 I was almost stressing out....

the issue isnt just writing lmao on the drive its also reading its doing both i literally tested it and it eats at your c drive where your windows is it does not even matter if you have it at a seperate drive if these people are saying you dont need to be worried and we tech people dk what we are talking about then why are the devs stepping in saying they will pass it to the tech guys not only that ik an IT guy who knows about these kinda of things so yes do not play the game till its fixed

haughty hull
#

A server provider discussing their run in with this issue: #📡│hosting-providers-chat message

One of the most interesting details (imo) is that even though they have several machines with close to identical hardware/software configs the disk usage issue only occurs on a small number of them.

haughty hull
#

Stumbled across this article whilst googling around to see how common using rocksdb for games is: https://borecraft.com/findings/windrose-rocksdb-findings.html
Lots of technical detail that I'm not really in a position to comment on that might be of interest

Windrose — RocksDB I/O and Write Amplification

A save-folder and engine-log analysis of the Windrose persistence pipeline — why the game sustains 15 to 30 MB per second of disk writes during routine play, and what the RocksDB tuning implies about the durability model.

#

Notably the author says that the configuration caps the WAL at a size that produces a vastly higher memtable flush rate than typical

#

Oh, another point of interest

The RocksDB LOG files on disk capture only DB open/shutdown banners (see § 06 · Backup Procedure), but the UE5 client log preserves the DAL layer's view of the same workload. The R5BLDalAsyncQueue::DetectProblems handler fires whenever a task exceeds its latency threshold.

I had no idea what R5BLDalAsyncQueue::DetectProblems was doing when I saw it in my R5.log but figured it wasn't responsible for the render loop freezing (the specific issue that had me looking for the cause, and seemed to coincide with 100% disk util bursts for me) for seconds at a time since it's called async, and assumed it was just some internal debug info monitoring. If this article is correct about its purpose then having 2600 lines like the following in my R5.log would explain a lot

Line 6237: [2026.04.21-10.01.21:778][510]R5LogBLDalAQ: Warning: [063510] R5BLDalAsyncQueue::DetectProblems [s:1774: 6169: commitT] EXTREMELY slow task. Task was finished in 21698 ms. DebugInfo

torn kelp
#

That is a really good link. The biggest takeaway for me is that it lines up with what a lot of players have been reporting about the game slowing down over time. The database layer does not seem to be keeping up with the persistence work being thrown at it, which means the save pipeline starts backing up.

That part is key. The queue keeps growing because the game is generating persistence work faster than the DB layer can drain it, and that is why commit times start getting worse as the session goes on. In the report, those commits climb from the low hundreds of milliseconds up to nearly 700 ms in places, which is a pretty good sign that the write pipeline is under pressure rather than staying stable.

The other big point is the 1 MB WAL cap. That is tiny. With that many column families sharing such a small WAL budget, it is forcing frequent flushes far earlier than you would want, which then feeds more SST creation and more compaction work. So even if the logical amount of game data being saved is not huge, the physical disk activity ends up much heavier because the same data keeps getting churned through the system.

Raising the WAL size, adding bytes per sync, and increasing background jobs all sound like sensible places to start. That should reduce the flush frequency, smooth out the write pattern, and ease some of the pressure on the queue. How much difference it would make, I cannot say, but it definitely looks like the right direction to investigate.

haughty hull
#

up to nearly 700 ms in places
yeah I mean in my own logs Im seeing it range 10 to 20 seconds lmao

forest dome
haughty hull
#

@proud current real quick regarding #1496921814431961178 message
is there any further information (game logs, db logs, system resource usage logs, etc) that would be useful for the dev team, or do they have everything they need right now?

proud current
haughty hull