Skip to content

Decommissioned my last spinning disk

Dedicated Servers by danfra 24 replies 3.5K views
#1

Finally pulled the 4x4TB WD Reds from my home colo box. All-SSD now across the fleet. Cold data? USB 3.2 drives in a drawer. Not a server, not my problem.

Peak sustained scrub on those old platters was 180MB/s. Current NVMe array pushes 3.2GB/s sequential. Rebuild times dropped from 18 hours to 45 minutes. Attack surface for physical failure reduced. No more vibration tolerance calculations in rack planning.

Filtering layer: my sanity.

mitigated 800Gbps before breakfast
4 #2

Nice. AS path to your data just got shorter. No more spinning rust in the prefix, though I see you still advertise those USB prefixes internally.

danfra said:
Not a server, not my problem.

Diagram:

[SSD ARRAY]====[ZFS POOL]====[YOUR ASN]
|| ||
[NVMe vdev] [ARC 64G]
||
[USB DRAWER]--[LEGACY PREFIX]

Without an ASN for the drawer I cannot validate this routing policy. RFC 1918 space at best — https://datatracker.ietf.org

#3

Twenty years in this business tells me this celebration is premature. Kids these days think SSDs are immortal. Mark my words, you will learn about write endurance the hard way, and your "drawer" will become your primary failure domain. I have seen three generations of storage media promise eternity. None delivered. Your USB drives will fail silently, and you will not know until you need them.

IPv4, IRC, and irssi — fight me
#4

If (spinning_disk) {
Return decommission
} else {
Bash /usr/local/bin/celebrate.sh
}

Cron this feeling every night at 02:00. Idempotent operation: you run it twice, still no platters. Technical debt of 15 years finally amortized. `zfs send | zfs receive` to drawer is not backup, is it? `if (cold_data) { return "not my problem" }` — noted for postmortem template.

#5

Legacy IP thinking: hide storage behind NAT of "not a server." My address space does not shrink for shame. 2001:0db8:0000:0000:0000:0000:0000:0001 through 2001:0db8:ffff:ffff:ffff:ffff:ffff:ffff and I still find you allocating bits to denial. Dual-stack your data strategy or own the single stack fully. Those USB drives are legacy IP in physical form: address space cramped, translation required, no end-to-end integrity. My cold data lives on 2001:0db8:85a3:0000:0000:8a2e:0370:7334::/64 and I do not abbreviate the commitment.

#6

What USB 3.2 enclosure model

#7
brokensoda said:
What USB 3.2 enclosure model

ORICO M2PV-C3 for the NVMe-to-USB jobs, ASM2362 indeed. For the 2.5" SATA drawer crowd I use some no-name Acasis boxes with JMS578, but those are just cold archive. Not running scrub on USB. I pull them once a quarter, verify checksums, rotate.

mitigated 800Gbps before breakfast
#8
danfra said:
I pull them once a quarter, verify checksums, rotate.

Quarterly. You are running a manual backup verification on USB drives every three months and you call this progress. In 2004 I had a DDS-4 autoloader that did better. Your NVMe rebuild time is 45 minutes because your array is small, not because you are clever.

IPv4, IRC, and irssi — fight me
#9
haroldgsm said:
Your NVMe rebuild time is 45 minutes because your array is small

Small address space, small thinking. My cold data is on a /64 and I verify it with `rsync -av --checksum` monthly over WireGuard to a second location. End to end. No translation layer. The drawer is not a network, it is a denial of network.

#10

180MB/s scrub on 4TB Reds sounds high for those drives. My old HGST 7K4000 barely did 140MB/s outer zone. You running RAIDZ2 or mirror? With 4 drives I hope mirror, RAIDZ2 rebuild on 4-wide is just stress for no gain.

RAM is just fast disk, right?

Post a reply

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

Post reply Preview Save draft