Skip to content
Register

CloudCone HDD storage VPS beats SSD on sustained sequential writes

VPS Hosting by Emre10 17 replies 5.1K views
gert0

Member

#11

Did anyone actually test this on the same node type or just different plans.

I ask because CloudCone runs mixed-density boxes on their storage line, so your "HDD" might be host-managed SMR with a generous rebuild buffer. That 180MB/s could be the cache zone, not the shingled platter. Would explain why it feels SSD-fast for 100GB.

DmitriEng said:
I had same thing on CloudCone, ssd plan tanked after 60GB

60GB sounds exactly like their older EVO-based cache tier. Newer nodes use different flash, not sure the drop is identical.

Anyone rerun this recently on a fresh provision? Curious if the gap still holds or if it was a firmware revision thing.

Emre10

Member OP

#12

17 days quiet but this still relevant

DmitriEng said:
I had same thing on CloudCone, ssd plan tanked after 60GB

60GB cache window is actually generous, some plans I tested hit wall at 20GB

For anyone finding this later: if your workload is large sequential writes (backups, video, logs), HDD storage VPS is not "worse" by default

Match the disk to the pattern like zoekyo said

Did you ever re-test with larger queue depth or direct=1? Curious if that changes the dropoff point

dancore

Member

#13

51 days late but this matches what I saw on my old RackNerd storage box too

The HDDs they use for bulk storage are basically datacenter drives meant to stream, not the SMR garbage you get in USB enclosures. Sequential is their whole job

DmitriEng said:
I had same thing on CloudCone, ssd plan tanked after 60GB

That 60GB number is suspiciously close to a common DRAM cache size, did you ever check if the drop happened at the same spot every run

ronwit

Member

Budget King

#14

53 days but this exact thing still happens, I saw it again last month on a different provider

DmitriEng said:
I had same thing on CloudCone, ssd plan tanked after 60GB

What tool did you use to catch the drop? I want to test my current backup box before I commit a full TB

instant noodles, instant deploys
DmitriEng

Member

#15

Still quiet here but I wanted to add: my 60GB drop was on the CloudCone "NVMe" tier, not their SATA SSD. So it's not just a controller bottleneck. The TLC itself hits a wall once the pSLC buffer empties.

Emre10 said:
Sustained matter more than burst

Exactly this. I moved that backup job to their HDD storage line and it's been rock steady at ~170MB/s for the full 400GB dataset. No surprises.

For anyone still on the fence: check your sustained numbers, not the CrystalDiskMark headline. The headline is basically a lie for large sequential writes.

marchhopper

Member

#16

This thread is still relevant.

DmitriEng said:
I had same thing on CloudCone, ssd plan tanked after 60GB
What size was the overall SSD plan? Curious if that 60GB wall maps cleanly to the SLC cache size or if the garbage collector just gave up.

blogfranck

Member

#17
DmitriEng said:
I had same thing on CloudCone, ssd plan tanked after 60GB

130 days late but did you ever try their HDD tier for the same workload? Curious if the cutoff was cleaner or if you just moved providers entirely

Emre10

Member OP

#18

132 days damn, thread still relevant though

DmitriEng said:
I had same thing on CloudCone, ssd plan tanked after 60GB

Exactly this, 60GB is the classic cache cliff on their older SSD nodes

Did you ever try the HDD plan for comparison or just moved on

Post a reply

You need an account to reply. Log in or register to join the conversation.

Post reply Preview Save draft