Romex Software Forum

So I got a server running m.2 DC p4511 as OS disk,

few days ago my server crashed, saying there's corrupted drive,
fortunately i kept daily backup.

So i restored the backup, but now sentinel says the drive is now 99%, only after 76 days of usage.

And i've been triying to figure out what's causing the health to drop so fast, so i checked the hdd sentinel stats :

Transfer Rate Information

Total Data Read,"930,023 MB, 33,729,218 MB since installation (8/23/2019)"

Total Data Write,"47,435 MB, 67,124,669 MB since installation"

Average Reads Per Day,"81,668.81 MB"

Average Writes Per Day,"162,529.46 MB"

Current Transfer Rate,"255,746 KB/s"

Average Transfer Rate,"253,344 KB/s"

Maximum Transfer Rate,"598,562 KB/s"

Current Read Rate,"251,615 KB/s"

Current Write Rate,"4,131 KB/s"

Current Disk Activity,100 %

Average Disk Activity,100.00 %

Estimated Max. Transfer Rate,"598,562 KB/s [520x DVD Write Speed]"

64tb write for 76 days!

No wonder i've had TWO 970 m.2 nvme died on this build before.
It's a media server, the high-write apps i could think of are emby radarr and sonarr, unfortunately those 3 don't allow installation on different drive. (at least not officially) There is also utorrent, blueiris, chrome, qbittorent, but i dont think they write too frequently.

So then i came across this page :
https://www.romexsoftware.com/en-us/pri ... -wear.html
I'm intrigued to try, but the last sentence worries me
"It is recommended that you may only enable Defer-Write on volumes where temporary, unimportant or reproducible data is to be stored."

I plan to use ramdisk as the destination disk and use the defer write feature
So is it safe to use it on OS drive for production environment? Some of the apps i mentioned need to retain their settings and data after reboot i think

If your system is stable (no crash, no freeze) and have an ups (no power loss), Defer-Write is safe. Otherwise, PrimoCache has no ways to flush deferred write-data from cache to target disks, thus data haven't been written will get lost if an ungraceful shutdown happens.

cemara wrote: ↑Sun Oct 11, 2020 3:27 am I plan to use ramdisk as the destination disk and use the defer write feature

Ramdisk also has such risks on ungraceful shutdowns.
PS. If you use ramdisk, defer-write is not needed on ramdisks.

Thanks for the answer, as alternative i'm thinking of using my drivepool (HDD, not SSD) as the target disk.
At the very least it has deduplication too.
I know it's odd to use slower drive as cache but i read somewhere HDD has better write cycle than SSD

If it's had 64TB write duty for 76 days something else is wrong, or you have an app that has extremely heavy drive use going on. It isn't Primocache causing the writes - it will actually coalesce writes AND discard redundant writes, which saves on SSD lifespan.

Over the last ~1.5 years on my primary work/gaming PC which I use anywhere from 4 to 16 hours a day every day, my OS NVMe has seen a total write duty of 7.2TB while using Primocache 100% of the time. Yours was over ten times higher in just 1.5 months.

If you believe either radarr or sonarr are responsible, get a separate drive for them and use Junction Link points to move their folders+data to the new drive, while leaving the junction links where they are on the C: drive.