Migration from i5 3470s to Ryzen 3600

[Junicast]

Hallo everybody

I've been running this hardware setup for several years now:
* Intel i5 3470s 2.9 - 3.6 GHZ with 4 Cores without HT and a TDP of 65W
* Gigabyte P67A-UD3-B3
* 32 GB RAM non ECC DDR3
* PCIe Intel Gigabit Card
* 5 x 4 TB HDD (spinning disks) as RAIDZ2 encrypted
* 1 x SanDisk Cruzer Blade flash drive for OS
* 1 x 100 GB SATA SSD for L2ARC and zil (partitioned)
* 1 x USB3 4 TB external HDD for backup purposes

I plan to migrate to new hardware in order to achieve this:
* Better CPU with same TDP
* ECC instead of non ECC
* more RAM
* more space for HDD
* faster IO

That's what I plan to migrate to:
* AMD Ryzen 3600 6 Cores with HD and TDP of 65W
* Asrock Taichi X470 (those X570 need too much power)
* 64 GB ECC DDR4
* keep PCIe Intel Gigabit Card for ez migration
* keep 5 x 4 TB HDD and some day migrate to 6 x 8 TB RaidZ2
* USB Flash drive for OS, haven't decided which one (USB3?)
* 1 x Samsung Evo 970 M.2 for zil (to boost write performance)
* No more SSD read cache as my RAM should suffice for that
* keep USB3 4 TB for backup

I plan to make a configuration backup and do a fresh install onto a new flash drive and restore. If you guys are interested in the outcome I will post my results and experiences with this new hardware. Some day I might migrate to 10G Ethernet because 1G is a bit too slow for this monster setup, right?
I appreciate any thoughts on my plans. If there's no showstopper I will order the hardware next week

 

[Ericloewe]

Asrock Taichi X470

Not a good choice. ECC support is dubious, for starters. It also lacks IPMI and associated features. The extra stuff is wasted and may in fact cause trouble (though it is unlikely) and will draw power for no good reason.

* keep PCIe Intel Gigabit Card for ez migration

It's really not needed. It's fairly likely that you'll need to reconfigure networking anyway, since any motherboard remotely worth considering will have at least one Intel GbE controller - right there, there's a 50/50 chance, at a minimum, that you'll need to reconfigure it.

* USB Flash drive for OS, haven't decided which one (USB3?)

In. the present day, a cheap NVMe M.2 SSD is a very superior option. USB flash drives are just too slow and unreliable to be worth it.

* 1 x Samsung Evo 970 M.2 for zil (to boost write performance)

It's dubious that you'd benefit from an SLOG, in general. Even if you do, that SSD is a horrible choice. Performance will be horrible (they're not at all optimized for latency) and it is very likely to fail exactly when it is needed, due to a lack of power loss protection. At that point, why not just use sync=disabled, have the same chance of losing data in transit and have better performance?

 

[Ericloewe]

You might want to take a look at this board: https://www.asrockrack.com/general/productdetail.asp?Model=X470D4U#Specifications
https://geizhals.de/asrock-rack-x470d4u-a2009567.html

 

[Junicast]

Thanks for the advice.
The only thing I don't get is the one referring to the M.2 write cache option.
Why wouldn't it speed up written transfers? I mean it's write cache and this one is supposed to be good at writing large amounts of data faster than my spinning RAIDZ2 would be able to.
My assumption was that even in sync mode it should be faster to write on SSD than on spinning (with sync also on), right? Even latency at writing should be much better with an SSD.
sync=disabled is no option for me. I like my data :D

 

[Ericloewe]

Why wouldn't it speed up written transfers? I mean it's write cache and this one is supposed to be good at writing large amounts of data faster than my spinning RAIDZ2 would be able to.

It is not a write cache. Maybe if you use a very broad definition...

ZFS' write cache is in RAM. There is nothing faster than RAM that you can use for this. Naturally, some data can't be considered written before it's actually written to something non-volatile, so ZFS has the ZFS Intent Log (ZIL) that does this. Since this is slow, you can offload it to a Separate LOG (SLOG) device if you need to process a lot of sync writes. It will not help you at all if you don't have sync writes. It is never read from under normal conditions - it will only be read from if the server crashes, loses power, etc.

My assumption was that even in sync mode it should be faster to write on SSD than on spinning (with sync also on), right?

You ultimately have to write stuff to the pool, so that's going to limit the bandwidth of your transfers (ZFS will throttle this automagically to keep things running smoothly). Of course, if you have a lot of sync writes, spinning rust will grind to a halt seeking around writing to the ZIL, wasting the few hundred IOPS it can do, so an SLOG makes sense.

sync=disabled is no option for me.

Question is, what in your workload is issuing sync writes?

 

[Junicast]

This Asrock Rack X470 isn't available. I will have to wait.

 

[Mastakilla]

fyi: I also didn't find X470 Asrock Rack mobos to be available in webshops. But after sending a mail to Asrock Rack they did bring me in contact with a shop that can deliver them by post (they just don't have a website advertising their products)

 

[Constantin]

I took a look at the SuperMicro EPYC series just to see if they might be an alternative to ASRock.

Unfortunately, the embedded EPYC 3000 series at SuperMicro seems to be a miss for storage applications. Yes, the boards are mini-ITX and (relatively) low power but they only offer up to 4 SATA slots on-board and gigabit networking. Some folk may be tempted to use the PCIe slot to put in a HBA and then hope for aggregating multiple gigabit links (which, as been discussed here, can be very problematic). These boards seem to be designed with a different intent than storage. The 7000-series boards seem to offer oodles of features, expansion capacity, are also much bigger, and likely need a lot more power.

Hopefully, SuperMicro decides to launch a flex-ATX version of the EPYC 3000 series with a built in LSI 2116 and the SFP+ port like my X10SDV-7TP4F. I'd take a look at the 2C version (i.e. the X10SDV-2C-7TP4F) on account of low power consumption, high clock speed, lots of I/O, SFP+, and relatively low cost). That would be a storage-oriented configuration allowing for a lot of flexibility, growth, and speed.

I don't doubt that EPYC will eventually re-write the price-points for server gear but for the moment, the selection of low-power storage-oriented EPYC gear is rather limited.