SSG-540P-E1CTR45L

[Fireball81]

Hello there,

i am planning a new TrueNAS build, to expand our current backup capacity.
At the moment i am considering the SuperMicro SSG-540P-E1CTR45L, a top loading storage server with 45 bays that uses the X12SPI-TF motherboard.

This is supposed to be a backup storage server for video production data so i would like to make the most efficient use out of the 45 drive bays.
I am planning to use 18TB drives, starting with 2x raidz2 VDEVs, consisting of 10 harddrives each. That would obviously leave me with 5 empty drive bays in case i go from 2 VDEVS to 4 in the future.

A bunch of questions i want to get out of the way from the start:

- The SSG-540P-E1CTR45L seems like a perfect fit for our use-case but do you guys have any experience with the E1CTR45L, recommendations or maybe even an advice why the E1CTR45L is not a good idea?

- Instead of going for 2x raidz2 VDEVs, each with 10 harddrives, would it be feasible to go for 11 harddrives in one VDEV instead? That would lead to 44 overall drives, once i expand the pool from 2x VDEVs to 4 and therefor would make more efficient use of the 45 drive bays i have. But i think i read somewhere in the past that you re not supposed to create VDEVs with odd drive numbers or go beyond a certain amount of drives for each VDEV but i can`t exactly remember and can only found old information on this topic.

Thank you in advance for your help and opinions.

 

[Arwen]

The wider the vDev, the more potential slowness. I don't remember all the details on that issue. Since it's backup storage, this might not be an issue.

Their is also possible wasted space on wide vDevs for small files. But, again that does not seem to apply in your use case of video files.

 

[Ericloewe]

- The SSG-540P-E1CTR45L seems like a perfect fit for our use-case but do you guys have any experience with the E1CTR45L, recommendations or maybe even an advice why the E1CTR45L is not a good idea?

Density is loud. This sort of thing needs a dedicated server room for sure.

- Instead of going for 2x raidz2 VDEVs, each with 10 harddrives, would it be feasible to go for 11 harddrives in one VDEV instead? That would lead to 44 overall drives, once i expand the pool from 2x VDEVs to 4 and therefor would make more efficient use of the 45 drive bays i have. But i think i read somewhere in the past that you re not supposed to create VDEVs with odd drive numbers or go beyond a certain amount of drives for each VDEV but i can`t exactly remember and can only found old information on this topic.

Think of it like this: Each vdev has approximately the same random performance as a single drive. This is not a big deal if you're dealing with large, sequential data. I have a vaguely similar workload at work (large satellite images plus their metadata, which is a bunch of smallish files) and run a 12-wide RAIDZ2. Performance won't set the world on fire, but it's perfectly adequate and hasn't bottlenecked anything yet. If you use four vdevs, expect something like four times the performance.
As for odd numbers of disks, it's not a major concern. I assume your video is compressed anyway, so the usual argument of "compression makes it irrelevant" doesn't apply, but the large files make it a bit irrelevant. Extra overhead is going to be negligible, probably.
Regardless of what you choose to do, definitely use recordsize=1M to significantly reduce the amount of metadata (and improve compression for anything compressible you might be storing).

 

[Fireball81]

Density is loud. This sort of thing needs a dedicated server room for sure.

Loudness is a concern for sure. Of course the server will be installed in an air conditioned server room but even thugh the room is fully isolated and there is a noise dampening door in there, a colleague is still working close to it. So far, the noise level was always more than acceptable with the hardware we already have but i think the 540P-E1CTR45L might push it a little bit to far.

As for odd numbers of disks, it's not a major concern. I assume your video is compressed anyway, so the usual argument of "compression makes it irrelevant" doesn't apply, but the large files make it a bit irrelevant. Extra overhead is going to be negligible, probably.

Yes, most of the video data is compressed in some way, regardless of what codec we are using. (Mostly RED and Blackmagic camera footage)